Barriers reconsidered, friendlier still!

Yang, Xi; Blackburn, Stephen M.; Frampton, Daniel; Hosking, Antony L.

doi:10.1145/2426642.2259004

Cited by 9 publications

(7 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Concurrent GC algorithms require mutator and GC threads to share ac o n s i s t e n tv i e wo ft h eh e a p .T h i si st y p i c a l l ya c h i e v e dt h r o u g h read or, more commonly, write barriers,w h i c hi m p o s eas m a l l overhead on mutator operations [25]. The synchronisation between mutator and GC is best described through the well-known tricolour abstraction [18].…”

Section: Concurrent Gcmentioning

confidence: 99%

Reference object processing in on-the-fly garbage collection

2014

View full text Add to dashboard Cite

Most proposals for on-the-fly garbage collection ignore the question of Java's weak and other reference types. However, we show that reference types are heavily used in DaCapo benchmarks. Of the few collectors that do address this issue, most block mutators, either globally or individually, while processing reference types. We introduce a new framework for processing reference types onthe-fly in Jikes RVM. Our framework supports both insertion and deletion write barriers. We have model checked our algorithm and incorporated it in our new implementation of the Sapphire on-thefly collector. Using a deletion barrier, we process references while mutators are running in less than three times the time that previous approaches take while mutators are halted;o u ro v e r a l le x e c u t i o n times are no worse, and often better.

show abstract

Section: Concurrent Gcmentioning

confidence: 99%

Reference object processing in on-the-fly garbage collection

2014

View full text Add to dashboard Cite

show abstract

“…RC Immix cons is only 1% slower than RC Immix on mutator time, with no programs degrading mutator time by more than 3%. Gen Immix, RC Immix and RC Immix cons all use write barriers which impose a direct mutator overhead [39]. Nonetheless, despite not requiring a write barrier, BDW consistently suffers the worst mutator overhead, 8% on average.…”

Section: Total Mutator and Collection Timementioning

confidence: 99%

Fast conservative garbage collection

2014

Self Cite

View full text Add to dashboard Cite

Garbage collectors are exact or conservative. An exact collector identifies all references precisely and may move referents and update references, whereas a conservative collector treats one or more of stack, register, and heap references as ambiguous. Ambiguous references constrain collectors in two ways.(1) Since they may be pointers, the collectors must retain referents. (2) Since they may be values, the collectors cannot modify them, pinning their referents.We explore conservative collectors for managed languages, with ambiguous stacks and registers. We show that for Java benchmarks they retain and pin remarkably few heap objects: <0.01% are falsely retained and 0.03% are pinned. The larger effect is collector design. Prior conservative collectors (1) use mark-sweep and unnecessarily forgo moving all objects, or (2) use mostly copying and pin entire pages. Compared to generational collection, overheads are substantial: 12% and 45% respectively. We introduce high performance conservative Immix and reference counting (RC). Immix is a mark-region collector with fine linegrain pinning and opportunistic copying of unambiguous referents. Deferred RC simply needs an object map to deliver the first conservative RC. We implement six exact collectors and their conservative counterparts. Conservative Immix and RC come within 2 to 3% of their exact counterparts. In particular, conservative RC Immix is slightly faster than a well-tuned exact generational collector. These findings show that for managed languages, conservative collection is compatible with high performance.

show abstract

“…This question was studied extensively by Blackburn and Hosking in 2004 [3], and a followup study in 2012 [22]. Their reported experimental results indicate average write barrier overheads in the range of 1-6% for the Java programs they study, for most of the write barrier types.…”

Section: Related Workmentioning

confidence: 99%

Allocation folding based on dominance

Clifford¹,

Payer²,

Starzinger³

et al. 2014

SIGPLAN Not.

View full text Add to dashboard Cite

Memory management system performance is of increasing importance in today's managed languages. Two lingering sources of overhead are the direct costs of memory allocations and write barriers. This paper introduces allocation folding, an optimization technique where the virtual machine automatically folds multiple memory allocation operations in optimized code together into a single, larger allocation group. An allocation group comprises multiple objects and requires just a single bounds check in a bump-pointer style allocation, rather than a check for each individual object. More importantly, all objects allocated in a single allocation group are guaranteed to be contiguous after allocation and thus exist in the same generation, which makes it possible to statically remove write barriers for reference stores involving objects in the same allocation group. Unlike object inlining, object fusing, and object colocation, allocation folding requires no special connectivity or ownership relation between the objects in an allocation group. We present our analysis algorithm to determine when it is safe to fold allocations together and discuss our implementation in V8, an open-source, production JavaScript virtual machine. We present performance results for the Octane and Kraken benchmark suites and show that allocation folding is a strong performance improvement, even in the presence of some heap fragmentation. Additionally, we use four hand-selected benchmarks JPEGEncoder, NBody, Soft3D, and Textwriter where allocation folding has a large impact.

show abstract

Barriers reconsidered, friendlier still!

Cited by 9 publications

References 20 publications

Reference object processing in on-the-fly garbage collection

Reference object processing in on-the-fly garbage collection

Fast conservative garbage collection

Allocation folding based on dominance

Contact Info

Product

Resources

About