An%20Adaptive,%20Region-based%20Allocator%20for%20Java

1

• An Adaptive, Region-based Allocator for Java

Feng Qian, Laurie Hendren fqian,
hendren_at_cs.mcgill.ca Sable Research
Group School of Computer Science McGill
University
2
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

3
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

4
Road Map

• Motivation Introduction
• Region-based Allocator
• Experimental Results
• Conclusion Future work

5
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

6
R2
R2
7
(No Transcript)
8
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

9
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

10
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

11
a new A()
1 a global_new A()
12
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

13
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
  

14
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

15
Specific Issues for Java

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

16
Road Map

• Motivation Introduction
• Region-based Allocator
• Experimental Results
• Conclusion Future work

17
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

18
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

19
R2
R1
c
b
a
20
Allocation Distribution
21
Effect of Regions and Page Sizes

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

22
collections collections collections collections froth rate froth rate froth rate
BASE 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
23
Behavior of Write Barriers
Write barriers for putfield, aastore
24
Region Allocation at Runtime
25
Effect of Adaptation
26
Effect of Adaptation (Cont.)
27
More on Adaptation

• Current scheme predicts future objects will
  escape after one object from that site escapes
• Without adaptation predicts future objects
  non-escaping

with adaptation with adaptation without adaptation without adaptation
collections froth collections froth
javac 15 29 96 589
jess 11 1 2 9
28
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)

29
Related Work

• Escape analysis and stack allocation for Java
  programs
• Gay et.al. CC00, Choi et.al. OOPSLA99,
  Blanchet OOPSLA99, Whaley et.al. OOPSLA99,
  
• Memory Management with Regions (Scoped memory
  regions)
• Tofte et.al.IC97, Gay et.al. PLDI98, Deters
  et.al. ISMM02,

30
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

31
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

32
?