Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
1
Pretenuring for Java™
Presented by Maria JumpSpecial Thanks to Steve Blackburn for the Power Point Presentation
Steve Blackburn, Sharad Singhai, Matthew Hertz,Kathryn McKinley & Eliot Moss
Architecture and Language Implementation LaboratoryDepartment of Computer Science, University of Massachusetts, Amherst
14 October 2003 CS395T – Memory Management 2
Where are they now?
• Steven M. Blackburn – Senior Lecturer, Australia National University
• Sharad Singhai– Sandbridge Technology
• Matthew Hertz – Graduate Student, University of Mass., Amherst
• Kathryn S. McKinely– Associate Professor, University of Texas at Austin
• J. Eliot B. Moss– Associate Professor, University of Mass., Amherst
14 October 2003 CS395T – Memory Management 3
Generational GC
• Advantage:– Fast allocation (via ‘bump pointer’)– Cheap reclamation (en masse)– Non-fragmenting– Minimizes copying of older objects
etc. etc …
‘nursery’ ‘older generation’
14 October 2003 CS395T – Memory Management 4
GC Can Be ExpensivePercentage of time spent in GC
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1.00 1.11 1.27 1.48 1.74 2.04 2.40 2.80 3.25
Heap size relative to minimum heap size (log scale)
Perc
enta
ge o
f tim
e sp
ent
in G
C SPEC _202_jess
SPEC _213_javac
SPEC _228_jack
health 6 128pBOB
2
14 October 2003 CS395T – Memory Management 5
Problem
Long lived objects copied at least once
14 October 2003 CS395T – Memory Management 6
Pretenuring
Allocate long lived objects directly into older generation– Identify long lived sites (via profiling)
[CHL98]– Modify to allocate into older generation
etc. etc …
‘nursery’ ‘older generation’
14 October 2003 CS395T – Memory Management 7
Pretenuring: our Goals
Pretenuring for JavaPretenuring for Java
• Apply pretenuring to Java• Generalize:
– different garbage collectors– program scales– different programs
• Apply to different collectors– Appel-style generational collector– Older-first collector
14 October 2003 CS395T – Memory Management 8
Object Lifetime Homogeneity
Pretenuring requires allocation site lifetime homogeneity– True for ML [CHL98]– Not true for C (call chain is necessary)
[BZ93]
What about Java?
3
14 October 2003 CS395T – Memory Management 9
Generalizing Pretenuring
GC-neutral Lifetime Statistics
• Lifetime– Time from birth to death of an object– Expressed w.r.t. min heap size
• Time of death– Point in program when object dies– Expressed w.r.t. total allocation
• Use profiling– Trace ‘birth’ and ‘death’ events– Very frequent GCs (e.g. every 64K)
(In the GC literature,‘time’ is usually expressed in terms of al location, not seconds)
14 October 2003 CS395T – Memory Management 10
Discussion Question
• 64K granularity in GC Profiling• What affects could profile granularity
have on the pretenuring decision?
14 October 2003 CS395T – Memory Management 11
Three-way Classification
• Short– Lived less than fraction s of a heap
• Immortal– Lifetime is longer than ‘deathtime’ (exploit fact
that non-copied space is half cost of copied space)
• Long– If neither short nor immortal
14 October 2003 CS395T – Memory Management 12
Object Lifetime DemographicsSPEC _213_javac
0.00
0.20
0.40
0.60
0.80
1.00
0.00 0.20 0.40 0.60 0.80 1.00
Lifetime
Tim
e of
dea
th
Immortal
LongShort
4
14 October 2003 CS395T – Memory Management 13
Mapping from Instance to Site
• Given 3 fractions: Sf, Lf, & If:– If Sf > Lf + If site is short– If Sf + Lf > If site is long– Otherwise site is immortal
• Given 3 fractions: Sf, Lf, & If:– If Sf > Lf + If site is short– If Sf + Lf > If site is long– Otherwise site is immortal
• Need to be conservative
• Given 3 fractions: Sf, Lf, & If, and a homogeneity factor, Hf:– If Sf + Hf > Lf + If site is short– Else if Sf + Lf + Hf > If site is long– Otherwise site is immortal
14 October 2003 CS395T – Memory Management 14
Discussion Question
• What other methods could be used to decide to pretenure an allocation site?
14 October 2003 CS395T – Memory Management 15
Pretenuring Mechanics
• Generate advice file– <class> <method> <offset> <[s|l|i]>
• Supply advice to compiler– Env. variable or command line option– Compiler generates map– Consults map for each new()– Compiles in appropriate allocation code
14 October 2003 CS395T – Memory Management 16
CHL Pretenuring
• CHL pretenuring advice:– Profile application using generational GC– Any site where 80% of allocated instances
‘survive’ the nursery is long-lived• Limitations
– Can’t easily combine advice– Collector-specific
5
14 October 2003 CS395T – Memory Management 17
Experimental Setting:Jikes RVM
(formally known as Jalapeño)
• JVM written in Java (see OOPSLA 99,00,01, PLDI 00,01)
– High performance– Aggressive optimizing compiler– Flexible GC toolkit
• ‘Boot image’ contains core classes (class loader, compiler etc.)
– Opportunity for application-neutral pretenuring– (Additional to application-specific pretenuring)
• GCTk, a OO GC toolkit with run-time and build-time ‘allocation advice’ implemented
14 October 2003 CS395T – Memory Management 18
Results
• UMass build-time advice is ‘true’ advice– Advice for each application based on profile
of remaining N-1 applications– Run-time advice is ‘self’ advice
• Used 5 benchmarks– 3 from SPEC JVM– 1 from Olden– IBM’s pBOB
• Measurements across 32 heap sizes
14 October 2003 CS395T – Memory Management 19
Mark/cons: geometric mean of 5 benchmarks
60%
70%
80%
90%
100%
110%
120%
130%
140%
1.08 1.27 1.48 1.74 2.04 2.40 2.80 3.25
Heap size relative to minimum heap size (log scale)
Mar
k/co
ns r
atio
rel
ativ
e to
no
PT UMass run time PT
UMass build time PTUMass run & build time PTCHL
14 October 2003 CS395T – Memory Management 20
GC time: geometric mean of 5 benchmarks
60%
70%
80%
90%
100%
110%
120%
1.08 1.27 1.48 1.74 2.04 2.40 2.80 3.25
Heap size relative to minimum heap size (log scale)
GC
time
rela
tive
to n
o PT
UMass run time PTUMass build time PT
UMass run & build time PTCHL
6
14 October 2003 CS395T – Memory Management 21
Execution time: geometric mean of 5 benchmarks
90%
92%
94%
96%
98%
100%
102%
104%
1.08 1.27 1.48 1.74 2.04 2.40 2.80 3.25
Heap size relative to minimum heap size (log scale)
Exec
utio
n tim
e re
lativ
e to
no
PT
UMass run time PT
UMass build time PTUMass run & build time PT
CHL
14 October 2003 CS395T – Memory Management 22
Pretenuring in the Older First GC Algorithm
• Older First [SMM99]– Efficient new copying GC algorithm– Different collection order to generational GC– Different heap layout to generational GC
• We add a permanent space (for immortals)
14 October 2003 CS395T – Memory Management 23
Older First GCExecution time: geometric mean of 5 benchmarks
65%
70%
75%
80%
85%
90%
95%
100%
105%
1.32 1.54 1.81 2.13 2.49 2.91
Heap size relative to minimum heap size (log scale)
Exec
utio
n tim
e re
lativ
e to
no
PT
UMass run time PT
UMass build time PTUMass run & build time PT
14 October 2003 CS395T – Memory Management 24
Conclusions
• Java programs are suitable for pretenuring• UMass pretenuring is general:
– Exploits ‘immortal’ objects– Combinable (suitable for build-time)– Collector neutral
• Applied to Jalapeño/Jikes RVM– Significant performance improvements– Build-time pretenuring highly practical (significant
benefits without application profiling)
7
14 October 2003 CS395T – Memory Management 25
The End