An Adaptive, Region-based Allocator for Java Feng Qian, Laurie Hendren {fqian, 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

R2 Thread Stack From Space To Space Heap Global Region R1 R2

Thread Stack From Space To Space Heap R1 Global Region R2

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 Global region contains escaping objects and objects created from non-local sites – A Free list 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

a = new A(); a.1 1: a = local_new A();b.f = a 1: a = global_new A(); ba.1

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

R2R1 b a c

Allocation Distribution

Effect of Regions and Page Sizes Dynamic measurement of: ● number of collections ● froth rate (unused bytes on pages)

# collections froth rate BASE2561K4K2561K4K compress777 (13%)70.03%0.11%0.47% db444 ( 0%)40.05%0.23%1.05% jack978 (23%)91.29%5.97%27.52% javac12 15 ( 9%)254.96%29.41%130.42% jess ( 7%)110.13%0.53%2.19% mpeg000 (28%)00.62%2.10%9.05% mtrt711 (81%)10.03%0.09%0.38% soot-c (19%)151.09%4.89%23.49% * 50M total heap space with ~25M in each semi-space

Behavior of Write Barriers Write barriers for putfield, aastore :

Region Allocation at Runtime

Effect of Adaptation

Effect of Adaptation (Cont.)

More on Adaptation with adaptationwithout adaptation #collectionsfroth#collectionsfroth javac1529%96589% jess11 1% 2 9% 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

?