41
Object Field Analysis for Heap Space Optimization ISMM 2004 G. Chen, M. Kandemir, N. Vijaykrishnanan and M. J. Irwin The Pennsylvania State Un iversity

Object Field Analysis for Heap Space Optimization ISMM 2004 G. Chen, M. Kandemir, N. Vijaykrishnanan and M. J. Irwin The Pennsylvania State University

Embed Size (px)

Citation preview

Object Field Analysis for Heap Space Optimization

ISMM 2004

G. Chen, M. Kandemir, N. Vijaykrishnanan and M. J. Irwin

The Pennsylvania State University

Spectrum of Java Technologies

From KVM White Paper (Sun Microsystems)

Heap Occupancy and Garbage CollectionSize

Heap Size

Time

Max Occupancy

GC GC GC GC GC

Total size of reachable objects

Total size of allocated objects

Life Cycle of a Java Object

o.f4

o.f3

o.f2

o.f1

o.f0 Time

Allocation

First access

Last access

Last reference removed Garbage

collected

Drag

Lifetime of object o

Dead

Field[Rojemo and Runcima 96], [Shaham et al. 2001]

Drag Time Reduction and Lazy AllocationSize

Heap Size

Time

Max Occupancy

GC GC GC

• Remove references to objects as soon as possible• Allocate objects as late as possible• Can we go further?

Life Cycle of the Fields

o.f4

o.f3

o.f2

o.f1

o.f0

Lifetime of o.f4

Time

Allocation

First access

Last access

Last reference removed Garbage

collected

Drag

Lifetime of object o

Dead

Field

Field Lifetime Aware Memory Management

• Manage the memory space in the granularity of fields– Allocate each field lazily– Allow collecting the fields that have been last accessed

• How much space can we save by managing the memory space in the granularity of fields?

• Can these potential savings be realized?– Possible for some applications

Experimental Setup

Spec JVM98Benchmarks

InstrumentedKaffe VM

Object AccessTrace

Trace Analyzer

Idle Field Ratio

F4

F3

F2

F1

F0

Time

Field lifetime Field idle time Lifetime ofthe Object

Field

• Idle Field Ration = Percentage of the idle area• How efficient an object uses the memory space

when management the heap at the object level?

Idle Field Ratio• Definition: idle field ratio of object o

– li: the length of lifetime of the ith field of object o

– Lo: the length of the lifetime of object o

– n: the number of fields of object o

• If most objects have low idle field ratio, field lifetime aware memory management is not worthwhile

• If most objects have high idle field ratio, field lifetime aware memory management might be worthwhile

o

n

ii

nL

lor

11)(

CDF of Idle Field Ratio

0%10%20%30%40%50%60%70%80%90%

100%

0% 20% 40% 60% 80% 100%

Idle Field Ratio

% of

Allo

cated

Mem

ory

Jess

Raytrace

(x%, y%): y% of the objects have an idle field ratio higher than x%

Potential of Filed Lifetime Aware Optimizations

• Field Last Use (FLU) – collect the space for each field as soon as the field is last used

• Field First Use (FFU) – Lazily allocate the space for each field upon the first access to this field

• Field First-Last Use (FFL) – Combination of FLU and FFU

Footprint (Jess)

0

20

40

60

80

100

120

0 100 200 300 400 500 600 700

Time (KB)

Heap

Occ

upan

cy (K

B)

Original FLU FFU FFL

Footprint (Raytrace)

0

200

400

600

800

1,000

1,200

1,400

1,600

0 200 400 600 800 1,000 1,200 1,400 1,600 1,800 2,000

Time (KB)

Heap

Occ

upan

cy (K

B)

Original FLU FFU FFL

Filed Lifetime Aware Max. Heap Occupancy

0%10%20%30%40%50%60%70%80%90%

100%je

ss

rayt

race db

java

c

mpe

gaud

io

jack

aver

age

jess

rayt

race db

java

c

mpe

gaud

io

jack

aver

age

Instance Instance + Array

Nor

mal

ized

Max

imum

Hea

p O

ccup

ancy

FLU FFU FFL

Compared with Object GranularityDrag Time Reduction + Lazy Allocation (Max. Occupancy)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%je

ss

rayt

race d

b

java

c

mp

egau

dio

jack

aver

age

No

rmal

ized

Max

imu

m H

eap

Occ

up

ancy

Determining Last Access

0%10%20%30%40%50%60%70%80%90%

100%

0 20 40 60 80 100 120 140 160 180 200

Number of Accesses

% o

f Las

t Use

d Fi

elds

jess

raytrace

Idle Space-Time Product

F4

F3

F2

F1

F0

Time

Field lifetime Field idle timeLifetime ofthe Object

Field

• Idle space-time product = the area of field idle time• How much space can be saved for each object?

Allocation Site Based Analysis

• Idle space-time product for object o– r(o): idle field ratio of object o– Bo: size of object o

– Lo: length of lifetime of object o

• Idle space-time product for allocation s– As: the set of the objects

allocated by s

ooLBorop )()(

sAo

opsP )()(

Idle Space-Time Product for Allocation Sites

0

100

200

300

400

500

600

700

800

0 10 20 30 40 50

Allocation Site

Idle

Spa

ce-T

ime

Prod

uct

Idle Space-Time Product for Allocation Sites (Raytrace)

05,000

10,00015,00020,00025,00030,00035,00040,00045,00050,000

0 5 10 15 20 25 30 35 40 45 50

Allocation Site

Idle

Spac

e-Ti

me P

rodu

ct

Life Cycle of the Fields

o.f4

o.f3

o.f2

o.f1

o.f0

Lifetime of o.f4

Time

Allocation

First access

Last access

Last reference removed Garbage

collected

Drag

Lifetime of object o

Dead

Field

Disjoint fieldsDisjoint fields

Read

Write

Using Union• Advantages:

– Allow disjoint fields in an object to share the same memory location

• Disadvantages:– Not safe

• Considering an integer field shares the memory space with a pointer

– Might introduce bugs

• Open question: is it worthwhile to incorporate union in Java?

Disjointness Analysis• Step 1: Build interference graph for each allocation

site– Each note represents a field– Edge (f1, f2): for at least one object that is allocated by

this allocation site, the values of fields f1 and f2 should be kept in the memory simultaneously

• Step 2: Combine interference graphs for the allocation sites that have the same accessing site

• Step 3: Determine object format for each allocation site

• Step 4: Evaluate memory savings

Disjointness Analysis – Example (1)

(s1)o = new C(…)

(s2)o = new C(…)

(s3)o = new C(…)

(a1)… o.f3 …

(a2)… o.f3 …

Disjointness Analysis – Example (2)

f1 f2

f3 f4

f1 f2

f3 f4

f1 f2

f3 f4

f1, f2, f3

f4

f1, f2

f3, f4

f1, f3, f4

f2

InterferenceGraph

Union

s1 s2 s3

(a1)… o.f3 …

(a2)… o.f3 …

0

1

0

1

0

1

Check object format at runtimeCheck object format at runtime

Disjointness Analysis – Example (3)f1 f2

f3 f4

f1, f2

f3

f4

f1, f3, f4

f2

CombinedInterference

Graph

Union

s1 s2 s3

(a1)… o.f3 …

(a2)… o.f3 …

0

1

0

1

f1 f2

f3 f4

2

f1, f2

f3

f4

0

1

2

Space Saving Potential of Using UnionsMax. Occupancy

0%10%20%30%40%50%60%70%80%90%

100%

jess

rayt

race

db

java

c

mpe

gaud

io jack

aver

age jess

rayt

race

db

java

c

mpe

gaud

io jack

aver

age

Instance Instance + Array

Norm

aliz

ed M

axim

um H

eap

Occ

upan

cy

Unmerged Merged

Space Saving Potential of Using UnionsAllocation Site Analysis (Jess)

02,0004,0006,0008,000

10,00012,00014,00016,00018,00020,000

0 5 10 15 20 25 30 35 40 45 50

Allocation Site

Size

Red

uctio

n (B

ytes

)

Space Saving Potential of Using UnionsAllocation Site Analysis (Raytrace)

010,00020,00030,00040,00050,00060,00070,00080,00090,000

100,000

0 10 20 30 40 50

Allocation Site

Size

Red

uctio

n (B

ytes

)

Components for Realizing Memory Savings

• A mechanism to dynamically expand/shrink the format of object instances

• An analysis strategy to identify last use points of each fields

• A mechanism for safe employment of field unions• An analysis strategy to identify the disjointness of

fields of the same object

Example – Jesspublic class Value { int _type; int intval; double floatval; Object Objectval; public Value(int v) { _type = INTEGER; intval = v; } public Value(double v) { … … } public Value (Object v) { … … }}

public class Value { public static class IntValue extends Value { int intval; public IntValue(int v) { intval = v; } public static class FloatValue extends Value { double floatval; } public static class ObjectValue extends Value { Object Objectval; }}

Example – RaytracePublic class OctNode { OctNode[ ] Adjacent; Face[ ] OctFace;

OctNode[ ] Child;

ObjNode ObjList; int NumObj; … …}

Public class OctNode { OctNode[ ] Adjacent; Face[ ] OctFace;

public class OctNode1 extends OctNode { OctNode[ ] Child; }

public class OctNode2 extends OctNode { ObjNode ObjList; int NumObj; }}

Conclusions• We investigate two related issues:

– The potential benefits of managing the heap space at a granularity that is smaller than an entire object

– The challenges for implementing a heap space management strategy dealing with entities that are smaller than an object

• We present the results of two analyses:– Field-level lifetime analysis– Field-level disjointness analysis

Thank [email protected]

Why Java?

• Cross-platform Compatibility– Especially important for the highly fragmented mobile

device market

• Enhanced user experiences– Rich GUI support– Dynamically downloading third-party applications

• Security• Mature developer community

Challenges• Slow CPU (compared to high end systems)• Limited energy supply

– Powered by batteries• Stringent memory budget

– 0.5 ~ 2 MB RAM– The available memory is increasing rapidly, but…

• More energy consumption• Higher price• Memory hungry new applications

Memory Components of JVMText SegmentC code of KVM

HeapLoaded classes,

Objects, Java exec stacks,

C-Stack

Data SegmentC variables,

Preloaded Class Lib

93KB

124KB

32KB

1~2MB

Filed Lifetime Aware Average Heap Occupancy

0%10%20%30%40%50%60%70%80%90%

100%je

ss

rayt

race

db

java

c

mpe

gaud

io jack

aver

age jess

rayt

race

db

java

c

mpe

gaud

io jack

aver

age

Instance Instance + Array

Norm

aliz

ed A

vera

ge H

eap

Occ

upan

cy

FLU FFU FFL

Compared with Object GranularityDrag Time Reduction + Lazy Allocation (Ave. Occupancy)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%je

ss

rayt

race db

java

c

mpe

gaud

io jack

aver

age

Norm

aliz

ed A

vera

ge H

eap

Occ

upan

cy

Space Saving Potential of Using UnionsAverage Occupancy

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%je

ss

ray

tra

ce

db

jav

ac

mp

eg

au

dio

jac

k

av

era

ge

jes

s

ray

tra

ce

db

jav

ac

mp

eg

au

dio

jac

k

av

era

ge

Instance Instance + Array

No

rma

lize

d A

ve

rag

e H

ea

p O

cc

up

an

cy

Unmerged Merged