View
212
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended