Liveness based Garbage Collection

Transcription

1 CS618: Program Analsis I st Semester Ideal Garbage Collection Liveness based Garbage Collection Ame Karkare karkare@cse.iitk.ac.in karkare@cse.iitb.ac.in Department of CSE, IIT Kanpur/Bomba... garbage collection (GC) is a form of automatic memor management. The garbage collector, or just collector, attempts to reclaim garbage, or memor occupied b objects that are no longer in use b the program.... From Wikipedia karkare, CSE, IITK/B CS618 1/36 karkare, CSE, IITK/B CS618 2/36 Real Garbage Collection Liveness based GC... All garbage collectors use some efficient approximation to liveness. In tracing garbage collection, the approximation is that an object can t be live unless it is reachable.... From Memor Management Glossar During execution, there are significant amounts of heap allocated data that are reachable but not live. Current GCs will retain such data. Our idea: We do a liveness analsis of heap data and provide GC with its result. Modif GC to mark data for retention onl if it is live. Consequences: Fewer cells marked. More garbage collected per collection. Fewer garbage collections. Programs expected to run faster and with smaller heap. karkare, CSE, IITK/B CS618 3/36 karkare, CSE, IITK/B CS618 4/36

2 The language analzed An Example First order eager Scheme-like functional language. In Administrative Normal Form (ANF). p Prog ::= d 1...d n e main d Fdef ::= (define (f x 1... x n) e) (if x e 1 e 2 ) e Expr ::= (let x a in e) (return x) k (cons x 1 x 2 ) a App ::= (car x) (cdr x) (null? x) (+ x 1 x 2 ) (f x 1... x n) (if (null?l1)l2 (cons (carl1) (append (cdrl1)l2)))) (letz (cons (cons 4 (cons 5 nil)) (cons 6 nil)) in (let (cons 3 nil) in (letw (appendz) in π:(car (cdrw))))) 3 w z 4 6 Though all cells are reachable at π, a liveness-based GC will retain onl the cells pointed b thick arrows. 5 karkare, CSE, IITK/B CS618 5/36 karkare, CSE, IITK/B CS618 6/36 Liveness Basic Concepts and Notations Demand Access paths: Strings over {0, 1}. 0 access car field 1 access cdr field Denote traversals over the heap graph z w (car (cdrw)) w z Liveness environment: Maps root variables to set of access paths. L i : z {ǫ} w {ǫ, 1, 10, 100} Alternate representation. L i : {z.ǫ} {w.ǫ, w.1, w.10, w.100} karkare, CSE, IITK/B CS618 7/36 Demand (notation: σ) is a description of intended use of the result of an expression. karkare, CSE, IITK/B CS618 8/36

3 Demand Liveness analsis The big picture Demand (notation: σ) is a description of intended use of the result of an expression. We assume the demand on the main expression to be (0+1), which we call σ all. The demands on each function bod, σ f, have to be computed. π main : (letz... in (let... in π 9 : (letw (appendz) in π 10 : (leta (cdrw) in π 11 : (letb (cara) in π 12 : (returnb))))))) π 1 : (lettest (null?l1) in π 2 : (iftest π 3 :(returnl2) π 4 : (lettl (cdrl1) in π 5 : (letrec (append tl l2) in π 6 : (lethd (carl1) in π 7 : (letans (cons hd rec) in π 8 : (returnans)))))))) karkare, CSE, IITK/B CS618 9/36 karkare, CSE, IITK/B CS618 10/36 Liveness analsis The big picture Liveness analsis π main : (letz... in (let... in π 9 : (letw (appendz) in π 10 : (leta (cdrw) in π 11 : (letb (cara) in π 12 : (returnb))))))) Liveness environments: L 1 =... L 2 = L 9 =... L 10 =... π 1 : (lettest (null?l1) in π 2 : (iftest π 3 :(returnl2) π 4 : (lettl (cdrl1) in π 5 : (letrec (append tl l2) in π 6 : (lethd (carl1) in π 7 : (letans (cons hd rec) in π 8 : (returnans)))))))) GOAL: Compute Liveness Environment at various program points, staticall. Lapp(a,σ) Liveness environment generated b an application a, given a demand σ. Lexp(e,σ) Liveness environment before an expression e, given a demand σ. karkare, CSE, IITK/B CS618 11/36 karkare, CSE, IITK/B CS618 12/36

4 Liveness analsis of Expressions Liveness analsis of Primitive Applications Lexp((return x), σ) = {x.σ} x Lexp((if x e 1 e 2 ),σ) = {x.ǫ} Lexp(e 1,σ) Lexp(e 2,σ) Lexp((let x s in e),σ) = L\{x. } Lapp(s, L(x)) where L = Lexp(e,σ) (car x) σ 0 Lapp((car x), σ) = {x.ǫ, x.0σ} Notice the similarit with: α live in (B) = live out (B)\kill(B) gen(b) in classical dataflow analsis for imperative languages. karkare, CSE, IITK/B CS618 13/36 karkare, CSE, IITK/B CS618 14/36 Liveness analsis of Primitive Applications Liveness Analsis of Function Applications x (cons x ) σ 0 1 Lapp((cons x ),σ) = {x.α 0α σ} {.β 1β σ} x (f x ) σ LF 1 f(α) ψ x LF 2 f(β) ψ Lapp((f x ),σ) = x.ψ x σ.ψ σ α β 0 Removal of a leading 0 1 Removal of a leading 1 α β Lapp((cons x ), σ) = x.0σ.1σ We use LF f : context independent summar of f. To find LF i f (...): Assume a smbolic demand σ sm. Let e f be the bod of f. Set LF i f(σ sm ) to Lexp(e f,σ sm )(x i ). How to handle recursive calls? Use LF f with appropriate demand!! karkare, CSE, IITK/B CS618 15/36 karkare, CSE, IITK/B CS618 16/36

5 Liveness analsis The big picture π main : (letz... in (let... in π 9 : (letw (appendz) in π 10 : (leta (cdrw) in π 11 : (letb (cara) in π 12 : (returnb))))))) Liveness environments: L l1 1 = {ǫ} 00σ append 1LF 1 append (1σ append) L l2 1 = σ LF 2 append (1σ append)... L 9 = LF1 append ({ǫ, 1} 10σ all) π 1 : (lettest (null?l1) in π 2 : (iftest π 3 :(returnl2) π 4 : (lettl (cdrl1) inσ π 5 : (letrec (append tl l2) in π 6 : (lethd (carl1) in π 7 : (letans (cons hd rec) in 1σ π 8 : (returnans)))))))) σ Demand summaries: LF 2 append(1σ) Function summaries: LF 1 append (σ) = {ǫ} 00σ 1LF 1 append (1σ) LF 2 append (σ) = σ LF2 append (1σ) Liveness analsis Demand Summar σ main = σ all π main : (letz... in (let... in σ 1 π 9 : (letw (appendz) in π 10 : (leta (cdrw) in π 11 : (letb (cara) in π 12 : (returnb))))))) Liveness environments: L l1 1 = {ǫ} 00σ append 1LF 1 append (1σ append) L l2 1 = σ LF 2 append (1σ append)... L 9 = LF1 append ({ǫ, 1} 10σ all) σ append = σ 1...σ 2 π 1 : (lettest (null?l1) in π 2 : (iftest π 3 :(returnl2) π 4 : (lettl (cdrl1) in σ 2 π 5 : (letrec (append tl l2) in π 6 : (lethd (carl1) in π 7 : (letans (cons hd rec) in π 8 : (returnans)))))))) Demand summaries: σ main = σ all σ append = {ǫ, 1} 10σ all 1σ append Function summaries: LF 1 append (σ) = {ǫ} 00σ 1LF 1 append (1σ) LF 2 append (σ) = σ LF2 append (1σ) karkare, CSE, IITK/B CS618 17/36 karkare, CSE, IITK/B CS618 18/36 Obtaining a closed form solution for LF Summar of Analsis Results Function summaries will alwas have the form: LF i f (σ) = Ii f Di f σ Consider the equation for LF 1 append Liveness at program points: Demand summaries: Function summaries: LF 1 append (σ) = {ǫ} 00σ 1LF1 append (1σ) Substitute the assumed form in the equation: I 1 append D1 append σ = {ǫ} 00σ 1(I1 append D1 append 1σ) Equating the terms without and with σ, we get: I 1 append = {ǫ} 1I1 append D 1 append = 00 1D1 append 1 L l1 1 = {ǫ} 00σ 1(I 1 append D1 append 1σ append) L l2 1 = {ǫ} I 2 append D 2 append 1σ append L l1 5 = {ǫ} 00σ append L tl 5 = I 1 append D1 append 1σ append L l2 5 = I 2 append D2 append 1σ append... σ append = {ǫ, 1} 1σ append 10σ all I 1 append = {ǫ} 1I1 append D 1 append = 00 1D1 append 1 I 2 append = I2 append D 2 append = {ǫ} D2 append 0 karkare, CSE, IITK/B CS618 19/36 karkare, CSE, IITK/B CS618 20/36

6 Solution of the equations Working of Liveness-based GC (Mark phase) View the equations as grammar rules: L l1 1 ǫ 00σ 1(I 1 append D1 append 1σ append) I 1 append ǫ 1I 1 append D 1 append 00 1D 1 append 1 The solution of L l1 1 is the language L(L l1 1 ) generated b it. GC invoked at a program point π GC traverses a path α starting from a root variable x. GC consults L x π: Does α L(L x π)? If es, then mark the current cell Note that α is a forward-onl access path consisting onl of edges 0 and 1, but not 0 or 1 But L(L x π) has access paths marked with 0/1 for 0/1 removal arising from the cons rule. karkare, CSE, IITK/B CS618 21/36 karkare, CSE, IITK/B CS618 22/36 0/1 handling GC decision problem 0 removal from a set of access paths: α 1 00α 2 α 1 α 2 α 1 01α 2 drop α 1 01α 2 from the set 1 removal from a set of access paths: α 1 11α 2 α 1 α 2 α 1 10α 2 drop α 1 10α 2 from the set Deciding the membership in a CFG augmented with a fixed set of unrestricted productions. 00 ǫ 11 ǫ The problem shown to be undecidable 1. Reduction from Halting problem. 1 Prasanna, Sanal, and Karkare. Liveness-Based Garbage Collection for Laz Languages, ISMM karkare, CSE, IITK/B CS618 23/36 karkare, CSE, IITK/B CS618 24/36

7 Practical 0/1 simplification Example The simplification is possible to do on a finite state automaton. Over-approximate the CFG b an automaton (Mohri-Nederhoff transformation). Perform 0/1 removal on the automaton. Grammar for L 9 L 9 I 1 append D1 append (ǫ 1 10σ all) I 1 append ǫ 1I 1 append D 1 append 00 1D 1 append 1 σ all ǫ 0σ all 1σ all After Mohri-Nederhoff transformation L 9 I 1 append D1 append (ǫ 1 10σ all) I 1 append ǫ 1I 1 append D 1 append 00 D 1 append 1D1 append D 1 append 1 D 1 append ǫ σ all ǫ 0σ all 1σ all karkare, CSE, IITK/B CS618 25/36 karkare, CSE, IITK/B CS618 26/36 Automaton for L 9 Experimental Setup 1 L 9 ǫ 1 1 0/1 ǫ 0 0 ǫ 1 0 Built a prototpe consisting of: An ANF-scheme interpreter Liveness analzer A single-generation coping collector /1 L 9 q 0 0 q 0 1 q 1 2 q 0 3 q 4 ǫ 1 0/1 1/1 1 L 9 q 0 0 q 0 6 q /1 0/1 L 9 q 0 0 q 0 1 q 0 5 q 2 1 0/1 L 9 q 0 0 q 6 ǫ The collector optionall uses liveness Marks a link during GC onl if it is live. Benchmark programs are mostl from the no-fib suite. karkare, CSE, IITK/B CS618 27/36 karkare, CSE, IITK/B CS618 28/36

8 GC behavior as a graph 1.89e e e e e Cells in active semi-space (LGC) Cells in active semi-space (RGC) No. of reachable cells No. of live cells Results as Tables Analsis Performance: Program sudoku lcss gc_bench knightstour treejoin nqueens lambda Time (msec) DFA size Precision(%) Garbage collection performance e+06 6e+06 9e e e+07 nqueens karkare, CSE, IITK/B CS618 29/36 Laz evaluation # Collected MinHeap GC time cells per GC #GCs (#cells) (sec) Program RGC LGC RGC LGC RGC LGC RGC LGC sudoku lcss gc_bench nperm karkare, CSE, IITK/B CS618 30/36 fibheap knightstour treejoin nqueens lambda Laziness: Example LGC collects more garbage than RGC. Garbage collection performance An evaluation strateg in which evaluation of an expression is postponed until its value is needed Binding of a variable to an expression does not force evaluation of the expression Ever expression is evaluated at most once # Collected MinHeap GC time (define (lengthl) cells per GC #GCs (define (#cells) (main) (sec) Program(if (null?l) RGC LGC RGC LGC (leta ( RGC LGC a BIG closure RGC) in LGC sudoku return 0 lcss (letb (+a1) 1701 in gc_benchreturn (+ 1 (length (cdrl))))) (letc (consbnil) in.075 nperm (letw (lengthc) in.9 fibheap (returnw)))))) knightstour treejoin nqueens lambda # collections of LGC no higher than RGC. Often, smaller. karkare, CSE, IITK/B CS618 31/36 Garbage collection performance karkare, CSE, IITK/B CS618 32/36

9 Handling laz semantics: Challenges Handling possible non-evaluation Laziness complicates liveness analsis itself. Data is made live b evaluation of closures In laz languages, the place in the program where this evaluation takes place cannot be staticall determined Liveness-based garbage collector significantl more complicated than that for an eager language. Need to track liveness of closures But a closure can escape the scope in which it was created Solution: carr the liveness information in the closure itself For precision: need to update the liveness information as execution progresses Liveness no longer remains independent of demand σ If (carx) is not evaluated at all, it does not generate an liveness forx Require a new terminal 2 with following semantics { if σ = 2σ {ǫ} otherwise Lapp((carx),σ) =x.{2, 0}σ karkare, CSE, IITK/B CS618 33/36 karkare, CSE, IITK/B CS618 34/36 Scope for future work Conclusions Reducing GC-time. Reducing re-visits to heap nodes. Basing the implementation on full Scheme, not ANF-Scheme Increasing the scope of the method. Laz languages. (Under review) Higher order functions. Specialize all higher order functions (Firstification) Analsis on the firstified program For partial applications, carr information about the base function Using the notion of demand for other analsis. Program Slicing Strictness Analsis All path problem, requires doing intersection of demands intersection of CFGs under-approximation Proposed a liveness-based GC scheme. Not covered in this talk: The soundness of liveness analsis. Details of undecidabilit proof. Details of handling laz languages. A prototpe implementation to demonstrate: the precision of the analsis. reduced heap requirement. reduced GC time for a majorit of programs. Unfinished agenda: Improving GC time for a larger fraction of programs. Extending scope of the method. karkare, CSE, IITK/B CS618 35/36 karkare, CSE, IITK/B CS618 36/36