Walking dead objects, or GC is always right (2019)

Automatic memory management is said to be one of the greatest features of Java as well as other managed programming languages. At the same time, JVM specification says almost nothing about how exactly it should work! As a result, there are so many various algorithms and strategies of Garbage Collection, each with its own benefits, trade-offs and implementation details. For example, different GCs answer the question "when should we reclaim an object that is considered to be garbage?" differently. It is not so obvious, and every answer can dramatically change the behaviour of an application. In this talk we will find out why GC store some dead objects on the heap, how this can influence your code and how to protect an application from zombie apocalypse.

Transcript

1. Ivan Ugliansky Huawei Technologies Walking dead objects or GC is always right

2. JVM engineer at Excelsior @ Huawei 2 Ivan Ugliansky ivan.ugliansky@gmail.com @dbg_nsk JUGNsk co-lead
3. 3 Automatic storage management system (Garbage Collector)
4. 4 Garbage Collector
5. 5 But what spec says? The Java Virtual Machine Specification, (§2.5.3): Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements.
6. 6 Expectation: ◦ Memory is somehow managed by JVM (the correctness is guaranteed) Garbage Collector
7. 7 Expectation: ◦ Memory is somehow managed by JVM (the correctness is guaranteed) ◦ A developer doesn’t worry about it Garbage Collector
8. 8 Garbage Collector Reality: java.lang.NullPointerException at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2640) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1501) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1465) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361) ... 3 more
9. 9 Garbage Collector Reality: java.lang.NullPointerException at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2640) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1501) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1465) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361) ... 3 more Exception in thread "1" java.lang.OutOfMemoryError: Java heap space at StressTimer$Task.run(StressTimer.java:10) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Exception in thread "2" java.lang.OutOfMemoryError: Java heap space at StressTimer$Task.run(StressTimer.java:10) at java.util.TimerThread.mainLoop(Unknown Source) ...
10. 10 Garbage Collector Reality: java.lang.NullPointerException at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2640) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1501) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1465) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361) ... 3 more Exception in thread "1" java.lang.OutOfMemoryError: Java heap space at StressTimer$Task.run(StressTimer.java:10) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Exception in thread "2" java.lang.OutOfMemoryError: Java heap space at StressTimer$Task.run(StressTimer.java:10) at java.util.TimerThread.mainLoop(Unknown Source) ... Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000e0000000, 257949696, 0) failed; error='Not enough space' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 257949696 bytes for committing reserved memory. # An error report file with more information is saved as:
11. 11 When exactly an object will be collected by GC?
12. 12 Agenda ◦ Different GC policies depending on liveness ◦ How does it affect the execution? ◦ How to take it into account? (and avoid OOM error)
13. 13 Tiny example
14. 14 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb
15. 15 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb
16. 16 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb
17. 17 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xmx768m Test
18. 18 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xmx768m Test arr1 ([I@4aa8f0b4) allocated Exception in thread "main" java.lang.OutOfMemoryError: ...
19. 19 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xcomp -Xmx768m Test
20. 20 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xcomp -Xmx768m Test arr1 ([I@4aa8f0b4) allocated arr2 ([I@9e89d68) allocated
21. 21 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xcomp -Xmx768m Test arr1 ([I@4aa8f0b4) allocated arr2 ([I@9e89d68) allocated
22. 22 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } Can GC collect arr1 here?
23. public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 23 Tiny example Visibility scope of arr1
24. public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 24 Tiny example Life range of arr1 Visibility scope of arr1
25. public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 25 Tiny example GC has full right to collect arr1 here
26. 26 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xmx768m Test arr1 ([I@4aa8f0b4) allocated Exception in thread "main" java.lang.OutOfMemoryError: ...
27. public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 27 Tiny example Interpreter has no idea variables’ liveness!
28. 28 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } Interpreter has no idea variables’ liveness! (and has to rely on the worst case)
29. 29 Story #1. Ghost Objects
30. 30 Story #1. Ghost Objects Weak references:
31. 31 Story #1. Ghost Objects Weak references: 1. java.lang.ref.* 2. Weakly reachable objects can be collected by GC
32. 32 Story #1. Ghost Objects Weak references: 1. java.lang.ref.* 2. Weakly reachable objects can be collected by GC 3. Can get «rotten»
33. 33 Story #1. Ghost Objects Weak references: 1. java.lang.ref.* 2. Weakly reachable objects can be collected by GC 3. Can get «rotten»
34. 34 Tiny example public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
35. 35 Tiny example public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
36. 36 Tiny example public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
37. 37 Tiny example public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); } java Test 1252585652 java -Xcomp Test Exception in thread "main" java.lang.NullPointerException
38. 38 Tiny example java Test 1252585652 java -Xcomp Test Exception in thread "main" java.lang.NullPointerException public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
39. But that’s not a real code, right? 39 Ghost Objects
40. 40 Ghost Objects java.lang.NullPointerException at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2640) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1501) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1465) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361) ... 3 more But that’s not a real code, right?
41. 41 The real code private static ResourceBundle getBundleImpl(..., ClassLoader loader, ...) { ... CacheKey cacheKey = new CacheKey(baseName, locale, loader); ... // use loader via cacheKey ... return bundle; }
42. 42 The real code private static ResourceBundle getBundleImpl(..., ClassLoader loader, ...) { ... CacheKey cacheKey = new CacheKey(baseName, locale, loader); ... // use loader via cacheKey ... return bundle; } actually a weak ref. loader’s last use
43. 43 The real code ◦ JDK 1.8.0_201 ◦ java.util.ResourceBundle.getBundle(...) ◦ -Xcomp + run in a loop ◦ JDK-8209184
44. 44 What can we do?
45. 45 What can we do? ◦ Check that a reference hasn't been nullified yet before use
46. 46 What can we do? ◦ Check that a reference hasn't been nullified yet before use ◦ Keep an object alive!
47. 47 What can we do? public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
48. 48 What can we do? public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); // use obj ??? }
49. 49 What can we do? public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); // use obj ??? } But how exactly should we use the object here?
50. 50 What can we do? public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); // use obj ??? } But how exactly should we use the object here? Compiler can eliminate or move a use!
51. 51 Keeping an object alive ◦ Pass as an argument ◦ Put into a field
52. 52 Keeping an object alive ◦ Pass as an argument ◦ Put into a field ◦ Reference.reachabilityFence(obj) Since Java 9
53. 53 Treatment public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); // use obj ??? }
54. 54 Treatment public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); Reference.reachabilityFence(obj); }
55. 55 Treatment private static ResourceBundle getBundleImpl(...) { ... CacheKey cacheKey = new CacheKey(baseName, locale, module, callerModule); ... // keep callerModule and module reachable for as long // as we are operating with WeakReference(s) to them // (in CacheKey) ... Reference.reachabilityFence(callerModule); Reference.reachabilityFence(module); return bundle; }
56. 56 Summary ◦ GC has full right to collect an object just after it’s last use ◦ The compiler has full right to eliminate or move variable uses ◦ Reference.reachabilityFence keeps an object alive
57. 57 Walking dead objects
58. 58 Walking dead objects An opposite problem: truly dead objects are not collected by GC by some reason.
59. 59 Walking dead objects
60. 60 Walking dead objects Some memory can be dragged to the next* GC cycle and that’s totally OK.
61. 61 Walking dead objects Huge Memory Drag ⇒
62. 62 Walking dead objects Huge Memory Drag ⇒ Many «zombie» objects ⇒
63. 63 Walking dead objects Huge Memory Drag ⇒ Many «zombie» objects ⇒ As a result: ◦ Unexpected OOMs ◦ java.lang.ref works poorly
64. 64 Story #2. F-reachables
65. 65 Story #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic.
66. 66 Story #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs.
67. 67 Story #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no ordering is specified among calls to finalize methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization.
68. 68 Story #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no ordering is specified among calls to finalize methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization.
69. 69 Story #2. F-reachables ➢ JDK 8 ㄧ 89 overrides of finalize()
70. 70 Story #2. F-reachables ➢ JDK 8 ㄧ 89 overrides of finalize() ➢ JDK 9 ㄧ 87 overrides (Object.finalize() is deprecated since 9)
71. 71 Story #2. F-reachables ➢ JDK 8 ㄧ 89 overrides of finalize() ➢ JDK 9 ㄧ 87 overrides (Object.finalize() is deprecated since 9) ➢ JDK 11 ㄧ 84 overrides
72. 72 Story #2. F-reachables Objects with nontrivial finalize(): ◦ survive longer
73. 73 Story #2. F-reachables Java Threads Finalizer Thread
74. 74 Story #2. F-reachables Java Threads Finalizer Thread STW GC Threads
75. 75 Story #2. F-reachables Java Threads Finalizer Thread STW GC Threads finalize() can’t be executed here!
76. 76 Story #2. F-reachables Objects with nontrivial finalize(): ◦ survive longer: at least (!) for one GC cycle in case of STW
77. 77 Story #2. F-reachables class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
78. class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } } 78 Story #2. F-reachables Foo ref ref is used in finalize, so it also survives
79. 79 Story #2. F-reachables ref is used in finalize, so it also survives as well as all reachable from ref objects! Foo ref class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
80. Objects with nontrivial finalize(): ◦ survive longer: at least (!) for one GC cycle in case of STW ◦ retain all reachable objects (f-reachables) 80 Story #2. F-reachables
81. How to notice a problem? 81 Developer vs F-reachables
82. 82 Developer vs F-reachables jmap -finalizerinfo <PID> How to notice a problem?
83. 83 Developer vs F-reachables jmap -finalizerinfo <PID> Unreachable instances waiting for finalization #instances class name ----------------------- 147532 StressTimer$FinalizeBallast 222 java.util.Timer$1 221 StressTimer$Task How to notice a problem?
84. 84 Developer vs F-reachables How you can fight F-reachables?
85. 85 Developer vs F-reachables Foo ref1 ref2 ref3 resource1 resource2 resource3 finalize() How you can fight F-reachables?
86. 86 Developer vs F-reachables Foo ref1 ref2 ref3 resource1 resource2 resource3 State state finalize() How you can fight F-reachables?
87. 87 Developer vs F-reachables How you can fight F-reachables?
88. What to use instead of finalize()? 88 Developer vs F-reachables
89. 89 Developer vs F-reachables java.lang.ref.Cleaner (old sun.misc.Cleaner) What to use instead of finalize()?
90. 90 Developer vs F-reachables Foo ref1 ref2 ref3 resource1 resource2 resource3 State state static class State implements Runnable { ... } static final Cleaner cleaner = Cleaner.create(); ... var foo = new Foo(); cleaner.register(foo, foo.getState()); finalize()
91. 91 Developer vs F-reachables Reduces Memory Drag since Java 9+! JDK-8071507 java.lang.ref.Cleaner (old sun.misc.Cleaner) What to use instead of finalize()?
92. 92 Summary ◦ finalize() increases Memory Drag ◦ JVM can handle it (but usually doesn’t care) ◦ java.lang.ref.Cleaner since Java 9
93. 93 Story #3. Nepotism Nepotism is based on favour granted to relatives in various fields, including business, politics, entertainment and other activities (c)
94. 94 Tiny example public class DummyList<E> { private Node<E> first; private Node<E> last; private class Node<E> { E value; Node<E> next; public Node(E value, Node<E> next) { ... } } }
95. 95 Tiny example public void addLast(Node n) { final var l = last; last = n; if (l == null) { first = n; } else { l.next = n; } }
96. 96 Tiny example public void removeFirst() { if (first != null) { var next = first.next; first = next; if (next == null) { last = null; } } } public void addLast(Node n) { final var l = last; last = n; if (l == null) { first = n; } else { l.next = n; } }
97. public void addLast(Node n) { final var l = last; last = n; if (l == null) { first = n; } else { l.next = n; } } 97 Tiny example public void removeFirst() { if (first != null) { var next = first.next; first = next; if (next == null) { last = null; } } }
98. 98 Story #3. Nepotism Generational GC: ◦ Young/Old generations ◦ Minor/Major GC
99. 99 Story #3. Nepotism Generational GC: ◦ Young/Old generations ◦ Minor/Major GC ◦ All young objects reachable from old gen should survive Minor GC
100. 100 Story #3. Nepotism Young Generation Old Generation
101. 101 Story #3. Nepotism new DummyList() DummyList first last Young Generation Old Generation
102. 102 Story #3. Nepotism DummyList first last Young Generation Old Generation
103. 103 Story #3. Nepotism DummyList first last Young Generation Old Generation
104. 104 Story #3. Nepotism DummyList first last DummyList.addLast(...) Young Generation Old Generation
105. 105 Story #3. Nepotism DummyList first last DummyList.addLast(...) Young Generation Old Generation
106. 106 Story #3. Nepotism DummyList first last DummyList.addLast(...) Young Generation Old Generation
107. 107 Story #3. Nepotism DummyList first last Young Generation Old Generation
108. 108 Story #3. Nepotism DummyList first last Young Generation Old Generation
109. 109 Story #3. Nepotism DummyList first last DummyList.removeFirst(...) Young Generation Old Generation
110. 110 Story #3. Nepotism DummyList first last DummyList.removeFirst(...) Young Generation Old Generation
111. 111 Story #3. Nepotism DummyList first last Young Generation Old Generation
112. 112 Story #3. Nepotism DummyList first last Young Generation Old Generation
113. 113 Story #3. Nepotism Generational GC consciously increases Memory Drag.
114. 114 Story #3. Nepotism Generational GC consciously increases Memory Drag. Old generation - a source of walking dead objects
115. 115 Story #3. Nepotism But that’s not a real code, right?
116. 116 Story #3. Nepotism Tony Printezis about fighting with nepotism of LinkedHashMap in TwitterJDK: https://youtu.be/M9o1LVfGp2A?t=1391 But that’s not a real code, right?
117. 117 How to notice a nepotism?
118. 118 How to notice a nepotism? Signs of nepotism: 1. Frequent and long Full GC pauses (use -XX:+PrintGCDetails) 2. A lot of suspicious live objects (see jmap -dump <PID>)
119. 119 How to fight nepotism?
120. 120 How to fight nepotism? ◦ Keep calm and wait for Full GC
121. 121 How to fight nepotism? ◦ Keep calm and wait for Full GC ◦ Manually nullify refs
122. 122 /** * Unlinks non-null first node f. */ private E unlinkFirst(Node<E> f) { final E element = f.item; final Node<E> next = f.next; f.item = null; f.next = null; // help GC ... } java.util.LinkedList: How to fight nepotism?
123. /** * Unlinks non-null first node f. */ private E unlinkFirst(Node<E> f) { final E element = f.item; final Node<E> next = f.next; f.item = null; f.next = null; // help GC ... } 123 java.util.LinkedList: How to fight nepotism?
124. 124 How to fight nepotism? ◦ Keep calm and wait for Full GC ◦ Manually nullify refs
125. 125 How to fight nepotism? ◦ Keep calm and wait for Full GC ◦ Manually nullify refs ◦ Tune size of young generation -Xmn -XX:NewRatio -XX:NewSize
126. 126 Walking dead objects Can GC just ignore an object and never collect it?
127. 127 Walking dead objects
128. 128 Story #4. Conservatism
129. 129 Precise GC public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); }
130. 130 Precise GC public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } How does GC know, which locales are alive at the moment?
131. 131 Precise GC stack sp+30h sp+0h registers rax rcx ... rdx r14
132. 132 Precise GC stack sp+30h sp+0h registers rax rcx ... rdx r14
133. 133 Precise GC stack sp+30h sp+0h registers rax rcx ... rdx r14
134. 134 Precise GC stack sp+30h sp+0h registers rax rcx ... rdx r14
135. 135 Precise GC ➢ Compiler support
136. 136 Precise GC ➢ Compiler support ➢ Stack and registers maps
137. 137 Precise GC ➢ Compiler support ➢ Stack and registers maps ➢ Maps only at safe-points!
138. 138 Conservative GC Can we do it without any hints from a compiler?
139. 139 Conservative GC ➢ Consider every value on the stack as a potential root ➢ Filter out obviously not references at runtime
140. 140 Conservative GC stack sp+30h sp+0h registers rax rcx ... rdx r14
141. 141 Conservative GC stack sp+30h sp+0h registers rax rcx ... rdx r14
142. 142 Conservative GC stack sp+30h sp+0h registers rax rcx ... rdx r14
143. 143 Conservative GC ➢ Consider every value on the stack as a potential root ➢ Filter out obviously not references at runtime ➢ Mistakes are possible, and it increases Memory Drag
144. 144 Conservative GC Why do this?
145. 145 Conservative GC Why do this? ➢ No maps ⇒ better memory footprint ➢ No maps ⇒ faster code generation
146. 146 Conservative GC Why do this? ➢ No maps ⇒ better memory footprint ➢ No maps ⇒ faster code generation ➢ No maps ⇒ no need for safe-points!
147. 147 Safe-points 1 - 2 instructions Backward branches and epilogues
148. 148 Safe-points 1 - 2 instructions Backward branches and epilogues Really expensive ⇒ optimized heavily in almost every JVM
149. 149 World without safe-points
150. 150 World without safe-points Greater performance Smaller code size
151. 151 World without safe-points Greater performance Smaller code size Many mechanisms in JVM should be reworked as they rely on safe-points
152. 152 Conservative GC Is it actually possible?
153. 153 Conservative GC Is it actually possible? In theory: Boehm GC, 1988, conservative Immix, 2008, mostly-precise
154. 154 Conservative GC Is it actually possible? In theory: Boehm GC, 1988, conservative Immix, 2008, mostly-precise In practice:
155. 155 Conservative GC Is it actually possible? In theory: Boehm GC, 1988, conservative Immix, 2008, mostly-precise In practice: MobiVM
156. 156 Conservative GC Is it actually possible? In theory: Boehm GC, 1988, conservative Immix, 2008, mostly-precise In practice: MobiVM scala-native
157. 157 Conservative GC Is it actually possible? In theory: Boehm GC, 1988, conservative Immix, 2008, mostly-precise In practice: MobiVM scala-native Excelsior JET Generation 1 (1999 - 2015)
158. 158 Unlimited Memory Drag Conservative mistake: ◦ usually an object survives for several additional GC cycles (until «false root» is on the stack)
159. 159 Unlimited Memory Drag Conservative mistake: ◦ usually an object survives for several additional GC cycles (until «false root» is on the stack) ◦ but sometimes an object stucks in the heap forever
160. 160 Unlimited Memory Drag public class Executor extends Thread { public abstract class Task implements Runnable { } final TaskQueue queue = new TaskQueue(); . . . }
161. 161 Unlimited Memory Drag public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } }
162. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 162 Unlimited Memory Drag stack sp+20h addr t
163. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 163 Unlimited Memory Drag stack addr t sp+20h
164. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 164 Unlimited Memory Drag stack addr t sp+20h
165. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 165 Unlimited Memory Drag stack addr t sp+20h
166. 166 Unlimited Memory Drag But that’s not a real code, right?
167. 167 Unlimited Memory Drag It is. This is java.util.Timer from JDK And it is even worse there But that’s not a real code, right?
168. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 168 Unlimited Memory Drag stack addr t sp+20h
169. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 169 Unlimited Memory Drag stack addr t sp+20h threadReaper
170. 170 Unlimited Memory Drag How can you fight with conservatism?
171. 171 Unlimited Memory Drag How can you fight with conservatism?
172. 172 Unlimited Memory Drag How can you fight with conservatism?
173. 173 java.util.Timer javadoc: After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur. By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel method. Unlimited Memory Drag
174. 174 Summary Conservative GC - great power, but also great responsibility
175. 175 Summary Conservative GC - great power, but also great responsibility Not only GC can be conservative! (look at the first tiny example)
176. 176 Tiny example public static void main(String[] args) { final int size = 512*1024*1024 / Integer.BYTES; int[] arr1 = new int[size]; System.out.println("arr1 (" + arr1 + ") allocated"); System.gc(); int[] arr2 = new int[size]; System.out.println("arr2 (" + arr2 + ") allocated"); } 512mb 512mb java -Xmx768m Test arr1 ([I@4aa8f0b4) allocated Exception in thread "main" java.lang.OutOfMemoryError: ...
177. 177 Conclusion
178. 178 Conclusion Please do not try to predict an object’s life time and rely on it in your code!
179. 179 Conclusion Please do not try to predict an object’s life time and rely on it in your code! And if you do: Use certified workarounds tools for that (reachabilityFence, Cleaner, Timer.cancel)
180. 180 Q & A @jugnsk ivan.ugliansky@gmail.com @dbg_nsk