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