Object Field Analysis for Heap Space Optimization ISMM 2004

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

2. Spectrum of Java Technologies From KVM White Paper (Sun Microsystems)

3. Heap Occupancy and Garbage Collection Size GC GC GC GC GC Heap Size Max Occupancy Total size of reachable objects Total size of allocated objects Time

4. Life Cycle of a Java Object [Rojemo and Runcima 96], [Shaham et al. 2001] Field o.f4 o.f3 Drag Dead o.f2 o.f1 Time o.f0 First access Last reference removed Lifetime of object o Garbagecollected Allocation Last access

5. Drag Time Reduction and Lazy Allocation Size GC GC GC Heap Size Max Occupancy • Remove references to objects as soon as possible • Allocate objects as late as possible • Can we go further? Time

6. Life Cycle of the Fields Field Lifetime of o.f4 o.f4 o.f3 Drag Dead o.f2 o.f1 Time o.f0 First access Last reference removed Lifetime of object o Garbagecollected Allocation Last access

7. 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

8. Experimental Setup Spec JVM98 Benchmarks Object Access Trace Trace Analyzer Instrumented Kaffe VM

9. Idle Field Ratio Field Lifetime ofthe Object Field idle time Field lifetime • Idle Field Ration = Percentage of the idle area • How efficient an object uses the memory spacewhen management the heap at the object level?

10. 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

11. CDF of Idle Field Ratio (x%, y%): y% of the objects have an idle field ratio higher than x%

12. 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

13. Footprint (Jess)

14. Footprint (Raytrace)

15. Filed Lifetime Aware Max. Heap Occupancy

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

17. Determining Last Access

18. Idle Space-Time Product Field Lifetime ofthe Object Field idle time Field lifetime • Idle space-time product = the area of field idle time • How much space can be saved for each object?

19. 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

20. Idle Space-Time Product for Allocation Sites

21. Idle Space-Time Product for Allocation Sites (Raytrace)

22. Life Cycle of the Fields Write Read Field Lifetime of o.f4 o.f4 Disjoint fields o.f3 Drag Dead o.f2 o.f1 Time o.f0 First access Last reference removed Lifetime of object o Garbagecollected Allocation Last access

23. 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?

24. 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

25. Disjointness Analysis – Example (1) (s1)o = new C(…) (s2)o = new C(…) (s3)o = new C(…) (a1)… o.f3 … (a2)… o.f3 …

26. Disjointness Analysis – Example (2) s1 s2 s3 f1 f2 f1 f2 f1 f2 Interference Graph f3 f4 f3 f4 f3 f4 0 0 0 Union 1 1 1 Check object format at runtime (a1)… o.f3 … (a2)… o.f3 …

27. Disjointness Analysis – Example (3) Combined Interference Graph f1 f2 f1 f2 f3 f4 f3 f4 s1 s2 s3 0 0 0 Union 1 1 1 2 2 (a1)… o.f3 … (a2)… o.f3 …

28. Space Saving Potential of Using UnionsMax. Occupancy

29. Space Saving Potential of Using UnionsAllocation Site Analysis (Jess)

30. Space Saving Potential of Using UnionsAllocation Site Analysis (Raytrace)

31. 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

32. Example – Jess 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; } } 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) { … … } }

33. Example – Raytrace Public class OctNode { OctNode[ ] Adjacent; Face[ ] OctFace; public class OctNode1 extends OctNode { OctNode[ ] Child; } public class OctNode2 extends OctNode { ObjNode ObjList; int NumObj; } } Public class OctNode { OctNode[ ] Adjacent; Face[ ] OctFace; OctNode[ ] Child; ObjNode ObjList; int NumObj; … … }

34. 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

35. Thank you! gchen@cse.psu.edu

36. 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

37. 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

38. Memory Components of JVM Text Segment C code of KVM 93KB Data Segment C variables, Preloaded Class Lib 124KB Heap Loaded classes, Objects, Java exec stacks, … 1~2MB C-Stack 32KB

39. Filed Lifetime Aware Average Heap Occupancy

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

41. Space Saving Potential of Using UnionsAverage Occupancy