1. An Adaptive, Region-based Allocator for Java Feng Qian & Laurie Hendren 2002

2. Roadmap n Stack allocation n A better algorithm n Implementation issues n Experiments results n Future enhancements

3. Stack Allocation - Advantages n Non Escaping objects can be allocated on the stack n Objects on the stack can be freed without GC intervention

4. Stack Allocation - Disadvantages n Static escape analysis requires whole program analysis –Can’t work with Dynamic Class Loading n Large arrays n Objects created in a loop with overlapping lifetimes

5. The Solution n Treat local regions as stack frames extensions n Stackable objects can be created in local regions n Regions which contain only non- escaping objects are freed when the stack frame is popped

6. Adaptive Escape Analysis n Dynamically categorize allocation sites as local or non-local n Detect escaping objects by write barriers –Mark region as dirty and give to GC –Mark allocation site as non-local n As execution proceeds, local regions are more likely to stay clean

7. Topics - Implementation n Regions n Escaping Objects n Allocation Sites n The Allocator

8. Regions n Region points to a list of pages in the heap n Token represents regions n Global and Free regions n Local regions

9. Global Region n Objects created in non-local allocation sites n Pages containing objects that have escaped local regions n Work with GC

10. Free Region n List of free pages n The Global and Local Regions takes pages from this region

11. Local Regions n Used as a stack extension n Assigned to activation’s stack frame n A method activation obtains a region by –getting a new region from the allocator –inheriting its caller’s region n New regions are freed before exiting

12. Escaping Objects n Escaping Object - pointed by an object in another region n Write barriers before bytecode instructions: –putstatic –putfield: lhs.f=rhs –aastore

13. Escaping Objects n What about methods returning objects ? –Inserting write barriers before bytecode areturn –Requiring all such methods to inherit caller’s region

14. Allocation Sites n Allocation sites are uniquely indexed n Allocation sites are all initialized to local n Each object stores its allocation site in its header n An allocation site becomes non-local when an object allocated at the site escapes n A bit vector is used to record states of allocation sites

15. The Allocator n Different GCs have different heap organizations –Mark & Sweep use a single space heap –Copying Collectors use two spaces heap –Generational Collectors use many spaces for aging areas n The heap we discuss is where new objects are allocated

16. Memory Organization

17. NewRegion n Free region tokens are managed by a stack n NewRegion pops a region and returns it n If no region is left then the Global region is returned

18. FreeRegion n If the Dirty field is clean, add the pages to the Free region n Else, add the pages to the Global region n Push region token to the tokens’ stack

19. Alloc n Only local sites allocate from local regions n First try to allocate memory from the first page n Add a new page if necessary n Look for a bunch of continuous pages for large object

20. Lazy Region Allocation n Many activation records have empty regions –methods that do not allocate objects –non-local allocations n Call NewRegion only when a new region is needed

21. Adaptive VM n Assign unique indexes to allocation sites at compilation n Store allocation site index in object header n Store region ID in the stack frame n Methods prologue and epilogue have more instructions n Write barriers before specific bytecodes

22. Prototype Implementation n Jikes RVM - baseline compiler n Semi-space copying collector n Fixed page size n Objects taking multiple pages

23. Experimental Results n Allocation sites n Effects of regions and page sizes on collections and fragmentation n Allocation behavior n Behavior of write barriers n Effect of adaptation

24. Allocation Sites

25. Effect of regions and page sizes on collections and fragmentation

26. Allocation Behavior

27. Behavior of write barriers

28. Region reclaimed space

29. Region allocated at runtime

30. Effect of adaptation

32. n Current scheme predicts future objects will escape after one object from that site escapes n Without adaptation predicts future objects non-escaping 9% 2 1%11jess 589%9629%15javac froth#collectionsfroth#collections without adaptationwith adaptation

33. Summary n Page size is important - overhead in froth and expensive searches is low n For many benchmarks a high percent of memory can be put in local regions n The average write barrier operations are low cost n Adaptation finds local sites

34. Runtime Improvements n The overhead of current implementation is still too high ! n Functions used by region management are written in Java n Ongoing work on a more optimized version

35. Possible Enhancements n Use more than one bit to find non-local allocation sites n Use a dirty bit per page and not per region n Periodically reset allocation sites to local

36. The End