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 Collection Size Heap Size Time Max Occupancy GC Total size of reachable objects Total size of allocated objects

Life Cycle of a Java Object o.f 4 o.f 3 o.f 2 o.f 1 o.f 0 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 Allocation Size Heap Size Time Max Occupancy 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.f 4 o.f 3 o.f 2 o.f 1 o.f 0 Lifetime of o.f 4 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 JVM98 Benchmarks Instrumented Kaffe VM Object Access Trace Trace Analyzer

Idle Field Ratio F4 F3 F2 F1 F0 Time Field lifetime Field idle time Lifetime of the 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 – l i : the length of lifetime of the i th field of object o – L o : 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

CDF of Idle Field Ratio (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)

Footprint (Raytrace)

Filed Lifetime Aware Max. Heap Occupancy

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

Determining Last Access

Idle Space-Time Product F4 F3 F2 F1 F0 Time Field lifetime Field idle time Lifetime of the 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 – B o : size of object o – L o : length of lifetime of object o Idle space-time product for allocation s – A s : the set of the objects allocated by s

Idle Space-Time Product for Allocation Sites

Idle Space-Time Product for Allocation Sites (Raytrace)

Life Cycle of the Fields o.f 4 o.f 3 o.f 2 o.f 1 o.f 0 Lifetime of o.f 4 Time Allocation First access Last access Last reference removed Garbage collected Drag Lifetime of object o Dead Field Disjoint 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 (f 1, f 2 ): for at least one object that is allocated by this allocation site, the values of fields f 1 and f 2 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) (s 1 ) o = new C(…) (s 2 ) o = new C(…) (s 3 ) o = new C(…) (a 1 ) … o.f 3 … (a 2 ) … o.f 3 …

Disjointness Analysis – Example (2) f1f1 f2f2 f3f3 f4f4 f1f1 f2f2 f3f3 f4f4 f1f1 f2f2 f3f3 f4f4 f 1, f 2, f 3 f4f4 f 1, f 2 f 3, f 4 f 1, f 3, f 4 f2f2 Interference Graph Union s1s1 s2s2 s3s3 (a 1 ) … o.f 3 … (a 2 ) … o.f 3 … Check object format at runtime

Disjointness Analysis – Example (3) f1f1 f2f2 f3f3 f4f4 f 1, f 2 f3f3 f4f4 f 1, f 3, f 4 f2f2 Combined Interference Graph Union s1s1 s2s2 s3s3 (a 1 ) … o.f 3 … (a 2 ) … o.f 3 … f1f1 f2f2 f3f3 f4f4 2 f 1, f 2 f3f3 f4f

Space Saving Potential of Using Unions Max. Occupancy

Space Saving Potential of Using Unions Allocation Site Analysis (Jess)

Space Saving Potential of Using Unions Allocation Site Analysis (Raytrace)

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 – Jess public 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 – Raytrace Public 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 you!

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 JVM Text Segment C code of KVM Heap Loaded classes, Objects, Java exec stacks, … C-Stack Data Segment C variables, Preloaded Class Lib 93KB 124KB 32KB 1~2MB

Filed Lifetime Aware Average Heap Occupancy

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

Space Saving Potential of Using Unions Average Occupancy