1. Michael Bond Kathryn McKinley The University of Texas at Austin Presented by Na Meng Most of the slides are from Mike’s original talk. Many thanks go to the authors.

2.  Memory bugs  Memory corruption: dangling pointers, double frees, buffer overflows  Memory leaks ▪ Lost objects: unreachable but not freed ▪ Useless objects: reachable but not used 2 Managed languages

3.  Memory leaks are a real problem  Managed languages do not eliminate them 3 Reachable Unreachable

4.  Memory leaks are a real problem  Managed languages do not eliminate them 4 Live ReachableDead

5.  Memory leaks are a real problem  Managed languages do not eliminate them 5 Live Reachable Dead

6.  Memory leaks are a real problem  Managed languages do not eliminate them 6 Live Reachable Dead

7.  Memory leaks are a real problem  Managed languages do not eliminate them  Slow & crash real programs 7 Live Dead

8.  Memory leaks are a real problem  Managed languages do not eliminate them  Slow & crash real programs  Fixing leaks is hard  Leaks take time to materialize  Failure far from cause 8  Leaks exist in production software

9. Leak Pruning  Precisely determine liveness of objects  Liveness is in general undecidable  Approximately treat stale objects as dead 9

10. 10 Live Reachable Dead

11. 11 Live Reachable Dead

12. 12 Live Reachable Dead

13. 13 Live Dead Throw OOM error Out of memory! Reachable

14. 14 Live Dead Out of memory! Throw OOM error Reclaim some objects Reachable

15.  Reclaim predicted dead objects 15 Reclaimed Live

16.  Reclaim predicted dead objects 16 Reclaimed Live a a b b

17.  Reclaim predicted dead objects  Poison references to reclaimed objects 17 Live a a ?

18.  Reclaim predicted dead objects  Poison references to reclaimed objects 18 Live a a

19.  Reclaim predicted dead objects  Poison references to reclaimed objects 19 Live a a X Throw InternalError with OOMError attached

20.  Reclaim predicted dead objects  Poison references to reclaimed objects 20 Live a a X Throw InternalError with OOMError attached Worst case: defers fatal errors Best case: keeps leaky programs running indefinitely Preserves semantics

21. 21 INACTI VE OBSER VE SELECTPRUNE Heap not nearly full <50% Heap filled >50% Heap not full Heap nearly full >90% Heap still nearly full

22.  Tracking staleness  o.staleCounter increments from k to k + 1 after 2 k garbage collections  Read barrier 22 o.staleCounter Header 001 b = a.f; //Application code if (b & 0x1){ // Read barrier //out-of-line code path t = b; // Save ref b &= ~0x1; // Clear lowest bit a.f = b;[iff a.f == t] // Atomic b.staleCounter = 0x0; //Atomic } How does staleCounter’s increment work?

23.  Maintaining edge table 23 a0a0 a0a0 b11b11 b11b11 src class  tgt class maxStaleUsebytesUsed b22b22 b22b22 A  B 2 0 b = a.f; //Application code if (b & 0x1){ // Read barrier //out-of-line code path t = b; // Save ref b &= ~0x1; // Clear lowest bit a.f = b;[iff a.f == t] // Atomic b.staleCounter = 0x0; //Atomic } if (b.staleCounter > 1){//set maxStaleUse edgeTable[a.class->b.class].maxStaleUse = max(edgeTable[a.class- >b.class].maxStaleUse, b.staleCounter);} if (b.staleCounter > 1){//set maxStaleUse edgeTable[a.class->b.class].maxStaleUse = max(edgeTable[a.class- >b.class].maxStaleUse, b.staleCounter);}

24.  Transitive Closure  Phase I: in-use transitive closure  Phase II: stale transitive closure 24 src class  tgt class maxStaleUsebytesUsed B  C0 E  C2 a10a10 a10a10 b10b10 b10b10 c13c13 c13c13 roots e10e10 e10e10 b20b20 b20b20 c23c23 c23c23 d13d13 d13d13 d23d23 d23d23 b30b30 b30b30 c33c33 c33c33 ▪ Enque candidate ref if tgt.staleCounter > 2 + ref.maxStaleUse ▪ Compute the bytes reachable from each stale candidate 60 80

25.  In-use transitive closure  Collector poisons each reference 25 a10a10 a10a10 b10b10 b10b10 c13c13 c13c13 roots e10e10 e10e10 b20b20 b20b20 c23c23 c23c23 d13d13 d13d13 d23d23 d23d23 b30b30 b30b30 c33c33 c33c33 src class  tgt class maxStaleUsebytesUsed B  C080 E  C2 ? ? ?

26. 26 a10a10 a10a10 b10b10 b10b10 roots e10e10 e10e10 b20b20 b20b20 b30b30 b30b30 c33c33 c33c33  Read barrier checks for poisoned references b = a.f; //Application code if (b & 0x1){ // Read barrier //out-of-line code path if (b.staleCounter > 1){ edgeTable[a.class->b.class].maxStaleUse = max(edgeTable[a.class->b.class].maxStaleUse, b.staleCounter);} if (b & 0x2){//Check if poisoned InternalError error = new InternalError(); err.initCause(avertedOutofMemoryError); throw err; if (b & 0x2){//Check if poisoned InternalError error = new InternalError(); err.initCause(avertedOutofMemoryError); throw err; X Throw InternalError ? ? ?

27. 27  Leaking pruning added to Jikes RVM 2.9.2  http://www.jikesrvm.org/Research+Archive http://www.jikesrvm.org/Research+Archive  Generational Mark-Sweep in MMTk  Performance stress test  Non-leaking programs: Dacapo & SPEC  Replay compilation  Leak tolerance test  Leaking programs

28. 28  SELECT State  5% overhead on Pentium 4  3% overhead on Core 2 Why overhead is negative for some benchmarks ?

29.  OBSERVE State 5%  SELECT State14% 29

30.  Insert read barrier  17% on average, 34% at most  Negligible compared with overall execution time 30

31. 31

35.  What about the leaked memory grows too fast?  What are the character of data structures involved with memory leak?  In addition to staleness, what else can we use to determine objects responsible for memory leak? 35