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

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

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

3. Example Read a token (new String) • Notice: String idName is often garbage Memory: Look up insymbol table 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); }} If not there, create new identifier, add to symbol table Compute onidentifier

4. Explicit Reclamation as the solution • Garbage does not accumulate Memory: 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); } elsefree(idName); computeOn(id); }} String idName is garbage, free immediately

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

6. Outline • Motivation • Analysis • Runtime support • Experimental evaluation • Conclusions

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

8. symbolTable id (global) Identifier idName readTokenString Pointer Analysis • Connectivity graph • Variables • Allocation sites • Globals (statics) • Analysis algorithm Flow-insensitive, field-insensitive String idName = stream.readToken(); Identifier id = symbolTable.lookup(idName); if (id == null) { id = new Identifier(idName); symbolTable.add(idName, id); } computeOn(id);

9. Pointer Analysis in more depth (1) Data Structures

10. Pointer Analysis in more depth (2)Calculating the Points-To relation void function(A p1, A p2, A p3) { v1 = new O p1.f = v1 p2 = p1.f p3 = p1 } p1 p2 p3 v1 Np1 Np2 Np3 O1 NI1 NI2 NI3

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

12. Generating summaries in more depth void function(A p1, A p2, A p3) { v1 = new O p1.f = v1 p2 = p1.f p3 = p1 } p1 p2 p3 v1 Getfield is needed because a single pointer link in summary may represent multiple pointers in the callee Np1 Np2 Np3 O1 NI1 NI2 NI3

13. symbolTable id (global) Identifier idName readTokenString The need for liveness analysis • Liveness identifies when objects become unreachable, not just whether or not they escape

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

15. Liveness Analysis • Computed as sets of edges • Variables • Heappointers String idName = stream.readToken(); idName Identifier id = symbolTable.lookup(idName); if (id == null) id = new Identifier(idName); (global) Identifier symbolTable.add(idName, id); readTokenString computeOn(id);

16. Where can we free it? • Where object exists -minus- • Where reachable String idName = stream.readToken(); readTokenString Identifier id = symbolTable.lookup(idName); if (id == null) id = new Identifier(idName); symbolTable.add(idName, id); Compiler inserts call to free(idName) computeOn(id);

17. Free placement issues • Select earliest point A, eliminate all B: A dom B • Deal with double free’s

18. Limitations & Extensions • Free-me frees short-lived objects with explicit pointers to them in the code • Factory variability • Potential extensions: • Container internals • interprocedural liveness & pointer analysis || shape analysis • Large data structures • Global context sensitive heap model • interprocedural liveness & pointer analysis

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

20. Experimental Evaluation

21. Increasing alloc size Increasing alloc size DaCapo benchmarks SPEC benchmarks Volume freed – in MB 74 91 98 105 180 183 263 271 103 348 515 523 716 822 1544 8195 100% 50% 0% db ps fop mtrt pmd antlr jess jack xalan bloat javac jython hsqldb raytrace compress pseudojbb

22. 73 73 45 163 673 278 30 222 FreeMe Mean: 32% 75 1607 34 24 57 16 22 0 Volume freed – in MB 74 91 98 105 180 183 263 271 103 348 515 523 716 822 1544 8195 100% 50% 0% db ps fop mtrt pmd antlr jess jack xalan bloat javac jython hsqldb raytrace compress pseudojbb

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

24. 20% 15% 6% Mark/sweep – time All benchmarks

25. 30% 9% Mark/sweep – GC time All benchmarks

26. GenMS – time All benchmarks Brings into question all techniques that target short-lived objects

27. GenMS – GC time Why doesn’t this help? Note: the number of GCs is greatly reduced All benchmarks FreeMe mostly finds short-lived objects Nursery reclaims dead objects for free (cost ~ survivors)

28. 12% Bloat – GC time

29. Embedded applications: Compile-ahead Memory constrained Non-moving collectors 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

30. Discussion • Are the percentages of freed memory good enough ? • Is compile-time memory management inherently incompatible with generational copying collection? • Abandon techniques that replace nursery? • How close is the actual gap between compiler analysis + ‘weaker’ GC aglorithms vs. generational collection