An Adaptive, Region-based Allocator for Java Feng Qian, Laurie Hendren {fqian, hendren}@cs.mcgill.ca...

An Adaptive, Region-based Allocator for Java

Feng Qian, Laurie Hendren{fqian, hendren}@cs.mcgill.ca

Sable Research GroupSchool of Computer Science

McGill University

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

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

Road Map

● Motivation & Introduction

Region-based Allocator

● Experimental Results

● Conclusion & Future work

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

R2

Th

read S

tack

From

Sp

ace

To S

pace

Heap

Global Region

R1 R2R2

Th

read S

tack

From

Sp

ace

To S

pace

Heap

R1

Global Region

R2

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

Heap Organization

● Heaps are managed as regions consisting of a set of pages: – A Global region contains escaping objects

and objects created from non-local sites

– A Free list links free pages

– Local regions act as extensions of stack frames, allocate spaces for objects created from local sites

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

a = new A();

a.1

1: a = local_new A();

b.f = a

1: a = global_new A();

ba.1

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

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

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

Specific Issues for Java

● areturn instruction● exceptions (and athrow instruction)● finalize method

Road Map

● Motivation & Introduction

● Region-based Allocator

Experimental Results

● Conclusion & Future work

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

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

R2 R1R1R1b

a

c

Allocation DistributionAllocation Behavior

80%

85%

90%

95%

100%

256

1K 4K 256

1K 4K 256

1K 4K 256

1K 4K

javac jess mtrt soot-c

Dis

trib

uti

on

firstpage nextpages searching

Effect of Regions and Page Sizes

Dynamic measurement of:● number of collections● froth rate (unused bytes on pages)

# collections froth rateBASE 256 1K 4K 256 1K 4K

compress 7 7 7 (13%) 7 0.03% 0.11% 0.47%

db 4 4 4 ( 0%) 4 0.05% 0.23% 1.05%

jack 9 7 8 (23%) 9 1.29% 5.97% 27.52%

javac 12 12 15 ( 9%) 25 4.96% 29.41% 130.42%

jess 12 11 11 ( 7%) 11 0.13% 0.53% 2.19%

mpeg 0 0 0 (28%) 0 0.62% 2.10% 9.05%

mtrt 7 1 1 (81%) 1 0.03% 0.09% 0.38%

soot-c 15 13 13 (19%) 15 1.09% 4.89% 23.49%

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

Behavior of Write BarriersWrite barriers for putfield, aastore :

80%

85%

90%

95%

100%

Dis

trib

uti

on

escaped

sameregion

samepage

null

quick

Region Allocation 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 (Cont.)

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

More on Adaptation

with adaptation without adaptation

#collections

froth #collections

froth

javac 15 29% 96 589%

jess 11 1% 2 9%

•Current scheme predicts future objects will escape after one object from that site escapes

•Without adaptation predicts future objects non-escaping

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)

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

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

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

?