320 likes | 454 Vues
An Adaptive , Region-based Allocator for Java. Feng Qian, Laurie Hendren {fqian, hendren}@cs.mcgill.ca Sable Research Group School of Computer Science McGill University. Motivation. Reduce GC work by object stack-allocation. Drawbacks of previous approach for Java
E N D
An Adaptive, Region-based Allocator for Java Feng Qian, Laurie Hendren {fqian, hendren}@cs.mcgill.ca Sable Research Group School of Computer Science McGill University
Motivation • Reduce GC work by object stack-allocation • Drawbacks of previous approach for Java • whole-program escape analyses • restrictions on stackable objects: • trivial finalize method • limited sizes of arrays • non-overlapping lifetime in a loop
Goals • Reduce GC work by cheaply reclaiming non-escaping objects, but: • should not rely on expensive program analyses • overcome restrictions of stack-allocation • Preserve full semantics of Java Virtual Machines • Explore runtime information of Java programs
Road Map • Motivation & Introduction • Region-based Allocator • Experimental Results • Conclusion & Future work
Proposal • Use write barriers to dynamically categorize allocation sites as local or non-local • Allocate objects in regions instead of stack frames • Adaptively change allocation decisions
Global Region Thread Stack R1 R2 From Space To Space Heap R2 R2
Global Region Thread Stack R1 R2 From Space To Space Heap
Definitions • Escaping Object: An object escapes its allocation region if and only if it is referenced by an object in another region • Non-local Allocation Site: An allocation site becomes non-local when an object created by that site escapes
Heap Organization • Heaps are managed as regions consisting of a set of pages: • A Globalregion contains escaping objects and objects created from non-local sites • AFreelist links free pages • Local regions act as extensions of stack frames, allocate spaces for objects created from local sites
Allocation Sites and Objects • Each allocation site has one unique index, with one of two states: • local, creates objects in local regions • non-local, creates object in the Global region • An object header contains: • the index of its allocation site (sharing space with thin locks) • an escaping bit
1: a = local_new A(); a.1 a.1 b b.f = a a = new A(); 1: a = global_new A();
Region Allocation • Method prologue and epilogue have instructions allocating and releasing regions • A region has one of two states: • clean: pages are reclaimed when the host stack frame popped • dirty: pages are appended to the Global region collected by GC
Write Barriers • Objects may escape local regions by four types of byte codes: putstatic, putfield, aastore, and areturn • Write barriers capturing escaping objects have two purposes: • safety: marking regions as dirty • adaptation: marking allocation sites as non-local
Put Them Together • Initially, all allocation sites in a method are in the local state • As the program proceeds, some become non-local, and will create future objects in the Global region • The local regions of future activations are more likely to be clean • Write barriers guarantee the safety
Specific Issues for Java • areturn instruction • exceptions (and athrow instruction) • finalize method
Road Map • Motivation & Introduction • Region-based Allocator • Experimental Results • Conclusion & Future work
Prototype Implementation • Jikes RVM: we choose the baseline compiler, and a semi-space copying collector • Settings: • Fixed page size • Did not use large object heap • Objects straddling multiple pages
Experimental Results • Behavior study of SPECjvm98 & soot-c: • Allocation behavior • Effect of regions and page sizes on collections and fragmentation • Behavior of write barriers • Effect of adaptation • Impact on thin locks
R1 R1 R1 R2 c b a
Effect of Regions and Page Sizes Dynamic measurement of: • number of collections • froth rate (unused bytes on pages)
Behavior of Write Barriers Write barriers for putfield, aastore :
More on Adaptation • Current scheme predicts future objects will escape after one object from that site escapes • Without adaptation predicts future objects non-escaping
Impact on Thin Locks • Share space with thin locks in a two-word object header. • Less than 5% of thin locks require one additional check on common path • One additional check on uncommon path (see the paper for details)
Related Work • Escape analysis and stack allocation for Java programs • Gay et.al. [CC’00], Choi et.al. [OOPSLA’99], Blanchet [OOPSLA’99], Whaley et.al. [OOPSLA’99], … • Memory Management with Regions (Scoped memory regions) • Tofte et.al.[IC’97], Gay et.al. [PLDI’98], Deters et.al. [ISMM’02], …
Conclusions • We have presented the idea of using regions to reduce the work of GC in Java Virtual Machines • We have implemented the prototype in a real virtual machine and proposed several techniques to reduce the overhead • Our study of allocation behavior validates the idea
Future Work • Relax definition of escaping by using stack discipline and region hierarchy • Look for better prediction schemes (calling context) • Optimize write barriers with cheap analyses • Combine the allocator with other types of GC