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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Memory Organization

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

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

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

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

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

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

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

Allocation Sites

Effect of regions and page sizes on collections and fragmentation

Allocation Behavior

Behavior of write barriers

Region reclaimed space

Region allocated at runtime

Effect of adaptation

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

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

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

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

The End