An Adaptive, Region-based Allocator for Java

Feng Qian & Laurie Hendren

2002

Roadmap

Stack allocation A better algorithm Implementation issues Experiments results Future enhancements

Stack Allocation - Advantages

Non Escaping objects can be allocated on the stack

Objects on the stack can be freed without GC intervention

Stack Allocation - Disadvantages

Static escape analysis requires whole program analysis– Can’t work with Dynamic Class Loading

Large arrays Objects created in a loop with

overlapping lifetimes

The Solution

Treat local regions as stack frames extensions

Stackable objects can be created in local regions

Regions which contain only non-escaping objects are freed when the stack frame is popped

Adaptive Escape Analysis

Dynamically categorize allocation sites as local or non-local

Detect escaping objects by write barriers– Mark region as dirty and give to GC– Mark allocation site as non-local

As execution proceeds, local regions are more likely to stay clean

Topics - Implementation

Regions Escaping Objects Allocation Sites The Allocator

Regions

Region points to a list of pages in the heap

Token represents regions Global and Free regions Local regions

Global Region

Objects created in non-local allocation sites

Pages containing objects that have escaped local regions

Work with GC

Free Region

List of free pages The Global and Local Regions takes

pages from this region

Local Regions

Used as a stack extension Assigned to activation’s stack frame A method activation obtains a region by

– getting a new region from the allocator– inheriting its caller’s region

New regions are freed before exiting

Escaping Objects

Escaping Object - pointed by an object in another region

Write barriers before bytecode instructions:– putstatic– putfield: lhs.f=rhs– aastore

Escaping Objects

What about methods returning objects ?– Inserting write barriers before bytecode

areturn– Requiring all such methods to inherit

caller’s region

Allocation Sites

Allocation sites are uniquely indexed Allocation sites are all initialized to local Each object stores its allocation site in its

header An allocation site becomes non-local when

an object allocated at the site escapes A bit vector is used to record states of

allocation sites

The Allocator

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 The heap we discuss is where new

objects are allocated

Memory Organization

NewRegion

Free region tokens are managed by a stack

NewRegion pops a region and returns it If no region is left then the Global region

is returned

FreeRegion

If the Dirty field is clean, add the pages to the Free region

Else, add the pages to the Global region Push region token to the tokens’ stack

Alloc

Only local sites allocate from local regions

First try to allocate memory from the first page

Add a new page if necessary Look for a bunch of continuous pages

for large object

Lazy Region Allocation

Many activation records have empty regions– methods that do not allocate objects– non-local allocations

Call NewRegion only when a new region is needed

Adaptive VM

Assign unique indexes to allocation sites at compilation

Store allocation site index in object header

Store region ID in the stack frame Methods prologue and epilogue have

more instructions Write barriers before specific bytecodes

Prototype Implementation

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

Experimental Results

Allocation sites Effects of regions and page sizes on

collections and fragmentation Allocation behavior Behavior of write barriers Effect of adaptation

Allocation Sites

Effect of regions and page sizes on collections and fragmentation

Allocation BehaviorAllocation Behavior

80%

85%

90%

95%

100%25

6

1K 4K 256

1K 4K 256

1K 4K 256

1K 4K

javac jess mtrt soot-c

Dis

trib

uti

on

firstpage nextpages searching

Behavior of write barriers

80%

85%

90%

95%

100%

Dis

trib

uti

on

escaped

sameregion

samepage

null

quick

Region reclaimed space

Region allocated at runtime

0%

20%

40%

60%

80%

100%

1 21 41 61 81 101 121 141 161 181 201 221 241 261

Bytes Allocated (per 1M)

Allo

ca

ted

on

Lo

ca

l R

eg

ion

s

soot-c

javac

jess

mtrt

Effect of adaptationJavac: ratio of clean regions 498K/499K

80%

85%

90%

95%

100%

1 51 101 151 201 251 301 351 401 451

Released Regions (per 1,000)

Ra

tio

of

Cle

an

Re

gio

ns

Effect of adaptation

Javac: ratio of clean regions with/without adaptation

0%

20%

40%

60%

80%

100%

1 21 41 61 81 101 121 141 161 181

Released Regions (per 10,000)

Rati

o o

f C

lean

Reg

ion

s adaptation

no adaptation

Effect of adaptation Current scheme predicts future objects

will escape after one object from that site escapes

Without adaptation predicts future objects non-escaping

9% 2 1%11jess

589%9629%15javac

froth#collectionsfroth#collections

without adaptationwith adaptation

Summary

Page size is important - overhead in froth and expensive searches is low

For many benchmarks a high percent of memory can be put in local regions

The average write barrier operations are low cost

Adaptation finds local sites

Runtime Improvements

The overhead of current implementation is still too high !

Functions used by region management are written in Java

Ongoing work on a more optimized version

Possible Enhancements

Use more than one bit to find non-local allocation sites

Use a dirty bit per page and not per region

Periodically reset allocation sites to local

The End