Free-Me: A Static Analysis for Automatic Individual Object Reclamation

Transcription

1 Free-Me: A Static Analysis for Automatic Individual Object Reclamation Samuel Z. Guyer, Kathryn McKinley, Daniel Frampton Presented by: Jason VanFickell Thanks to Dimitris Prountzos for slides adapted from the original PLDI talk

2 Motivation Automatic memory reclamation (GC) No need for explicit free Garbage collector reclaims memory Eliminates Can we combine many programming the software errors engineering advantage of garbage collection with the low-cost incremental reclamation of Frequent explicit GCs: memory management? Problem: when do we get memory back? Reclaim memory quickly (minimize memory footprint), with high overhead Infrequent GCs: Lower overhead, but lots of garbage in memory

3 Example Read a token (new String) void parse(inputstream stream) { while (not_done) { String idname = stream.readtoken(); Identifier id = symboltable.lookup(idname); if (id == null) { id = new Identifier(idName); symboltable.add(idname, id); computeon(id); Notice: String idname is often garbage Memory: Compute on identifier Look up in symbol table If not there, create new identifier, add to symbol table

4 Explicit Reclamation as the solution void parse(inputstream stream) { while (not_done) { String idname = stream.readtoken(); Identifier id = symboltable.lookup(idname) if (id == null) { id = new Identifier(idName); symboltable.add(idname, id); else free(idname); computeon(id); String idname is garbage, free immediately Garbage does not accumulate Memory:

5 FreeMe as the solution Adds free() automatically FreeMe compiler pass inserts calls to free() Preserve software engineering benefits Can t determine lifetimes for Potential: all objects 1.7X performance Works with the garbage collector malloc/free vs GC in tight heaps Goal: Implementation of free() depends on collector (Hertz & Berger, OOPSLA 2005) Incremental, eager memory reclamation Results: reduce GC load, improve performance

6 Goal: FreeMe Analysis Determine when an object becomes unreachable Within a method, for allocation site p = new A where can we place a call to free(p)? Not a whole-program analysis* Idea: pointer analysis + liveness Pointer analysis for reachability Liveness analysis for when I ll describe the interprocedural parts later

7 Pointer Analysis String idname = stream.readtoken(); Identifier id = symboltable.lookup(idname); if (id == null) { id = new Identifier(idName); symboltable.add(idname, id); computeon(id); Connectivity graph id symboltable Variables Allocation sites Globals (statics) Analysis algorithm Flow-insensitive, field-insensitive Identifier (global) readtoken String idname

8 Pointer Analysis in more depth

9 Calculating the Points-To relation void function(a p1, A p2, A p3) { v1 = new O p1.f = v1 p2 = p1.f p3 = p1 v1 p1 p2 p3 O1 i, P t s T o ( p i ) = { N P i P t s T o ( p " i, P t s 1 ) = { N T o ( N P P i ) 1, O = { 1 N I i P t s T o ( p " i, P t s 2 ) = { N T o ( N P I ) 1, O = { 1, N N I i I 1, N P 2 i P t s T o ( p 3 ) = { N P 1, N P 3 N p1 N I1 N p2 N I2 N p3 N I3

10 Interprocedural component Detection of factory methods String idname = stream.readtoken(); Return value is a new object Can be freed by the caller Effects of methods called symboltable.add(idname, id); Hashtable.add: (0 1) (0 2) Describes how parameters are connected Compilation strategy: Summaries pre-computed for all methods Free-me only applied to hot methods

11 Generating summaries in more depth void function(a p1, A p2, A p3) { v1 = new O p1.f = v1 p2 = p1.f p3 = p1 getfield is needed because a single pointer link in summary may represent multiple pointers in the callee v1 O1 p1 N p1 p2 N p2 p3 N p3 P t s T o ( p 1 ) = { N P 1, O 1 P t s T o ( p 2 ) = { N P 1, O 1, N I 1, N P 2 P t s T o ( p 3 ) = { N P 1, N P 3 N I N I N I ( p 2, p 1 ), ( p 2, * p 1 ) ( p 3, p 1 )

12 The need for liveness analysis When objects become unreachable, not just whether or not they escape id symboltable (global) Identifier idname readtoken String

13 Adding Liveness Key : An object is reachable only when all incoming pointers are live idname (global) Identifier readtoken String Reachability is union of all these live ranges From a variable: From a global: From other object: Live range of the variable Live from the pointer store onward Live from the pointer store until source object becomes unreachable

14 Liveness Analysis Computed as sets of edges Variables idname Heap pointers String idname = stream.readtoken(); Identifier id = symboltable.lookup(idname); if (id == null) id = new Identifier(idName); Identifier (global) symboltable.add(idname, id); readtoken String computeon(id);

15 Where can we free it? Where object exists readtoken String -minus- Where reachable Compiler inserts call to free(idname) String idname = stream.readtoken(); Identifier id = symboltable.lookup(idname); if (id == null) id = new Identifier(idName); symboltable.add(idname, id); computeon(id);

16 Free placement issues Select earliest point A,eliminate all B: A dom B Deal with double free s

17 Runtime support for FreeMe Run-time: depends on collector Mark/sweep Free-list: free() operation Generational mark/sweep Unbump: move nursery bump pointer backward (LIFO frees) Unreserve: reduce copy reserve Very low overhead Run longer without collecting Size to free defined statically/dynamically (query object)

18 Experimental Evaluation

19 Volume freed in MB 100% % Increasing alloc size Increasing alloc size SPEC benchmarks DaCapo benchmarks 0% db raytrace mtrt javac pseudojbb compress jack jess fop jython hsqldb ps antlr pmd bloat xalan

20 Volume freed in MB 100% FreeMe Mean: 32% % 0% db mtrt raytrace 0 pseudojbb compress javac fop jack jess jython hsqldb ps antlr pmd bloat xalan

21 Comparing FreeMe & other approaches Stack-like free() allocations of same method Restrict free instrumentation to end of method No factory methods No conditional freeing Uncond Prove objects dead on all paths Influence of free on some paths

22 Mark/sweep time 20% All benchmarks 15% 6%

23 Mark/sweep GC time 30% All benchmarks 9%

24 GenMS time All benchmarks Brings into question all techniques that target short-lived objects

25 GenMS GC time Why doesn t this help? All benchmarks Note: the number of GCs is greatly reduced FreeMe mostly finds shortlived objects Nursery reclaims dead objects for free (cost ~ survivors)

26 12% Bloat GC time

27 Conclusions FreeMe analysis Finds many objects to free: often 30% - 60% Most are short-lived objects GC + explicit free() Advantage over stack/region allocation: no need to make decision at allocation time Generational collectors Nursery works very well Mark-sweep collectors 50% to 200% speedup Works better as memory gets tighter Embedded applications: Compile-ahead Memory constrained Non-moving collectors

28 Discussion Is compile-time memory management inherently incompatible with generational copying collection? Is the amount of memory freed significant? Could static analysis allow mark-sweep collectors to compete with generational collectors?