An Adaptive , Region-based Allocator for Java

1. 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

2. 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

3. 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

4. Road Map • Motivation & Introduction • Region-based Allocator • Experimental Results • Conclusion & Future work

5. 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

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

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

8. 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

9. 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

10. 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

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

12. 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

13. 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

14. 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

15. Specific Issues for Java • areturn instruction • exceptions (and athrow instruction) • finalize method

16. Road Map • Motivation & Introduction • Region-based Allocator • Experimental Results • Conclusion & Future work

17. 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

18. 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

19. R1 R1 R1 R2 c b a

20. Allocation Distribution

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

22. * 50M total heap space with ~25M in each semi-space

23. Behavior of Write Barriers Write barriers for putfield, aastore :

24. Region Allocation at Runtime

25. Effect of Adaptation

26. Effect of Adaptation (Cont.)

27. More on Adaptation • Current scheme predicts future objects will escape after one object from that site escapes • Without adaptation predicts future objects non-escaping

28. 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)

29. 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], …

30. 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

31. 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

32. ?