Walking dead objects, or GC is always right (Joker 2018)

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.

1. Иван Углянский Excelsior LLC Ходячие объекты-мертвецы или GC всегда прав
2. JVM инженер в проекте Excelsior JET ◦ разрабатываю рантайм 2 Иван Углянский iugliansky@excelsior-usa.com @dbg_nsk JUGNsk co-lead
3. 3 Excelsior JET JVM Java compatible ◦ Лицензиаты Oracle ◦ JCK каждую ночь
4. 4 Excelsior JET JVM Java compatible ◦ Лицензиаты Oracle ◦ JCK каждую ночь Честный AOT ◦ Межпроцедурные оптимизации ◦ JIT для подгружаемых классов ◦ Интерпретатора нет
5. 5 Excelsior JET JVM Java compatible ◦ Лицензиаты Oracle ◦ JCK каждую ночь Честный AOT ◦ Межпроцедурные оптимизации ◦ JIT для подгружаемых классов ◦ Интерпретатора нет JET team blog: www.excelsiorjet.com/blog
6. 6 Автоматическое управление памятью (Сборка мусора)
7. 7 Сборка мусора
8. 8 А что в спеке? 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.
9. 9 Сборка мусора Ожидание: ◦ JVM собирает мусор, как хочет (в рамках корректности)
10. 10 Сборка мусора Ожидание: ◦ JVM собирает мусор, как хочет (в рамках корректности) ◦ Разработчик не задумывается об управлении памятью
11. 11 Сборка мусора Реальность: 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
12. 12 Сборка мусора Реальность: 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) ...
13. 13 Сборка мусора Реальность: 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:
14. 14 Когда конкретно GC придет за объектом?
15. 15 В этом докладе ◦ Про политики GC относительно времени жизни объектов на примерах ◦ Как это влияет на исполнение? ◦ Как не получить OOM это учитывать в коде?
16. 16 Разминка
17. 17 Разминка 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
18. 18 Разминка 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
19. 19 Разминка 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
20. 20 Разминка 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
21. 21 Разминка 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: ...
22. 22 Разминка 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
23. 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"); } 512mb 512mb java -Xcomp -Xmx768m Test arr1 ([I@4aa8f0b4) allocated arr2 ([I@9e89d68) allocated
24. 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"); } 512mb 512mb java -Xcomp -Xmx768m Test arr1 ([I@4aa8f0b4) allocated arr2 ([I@9e89d68) allocated
25. 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"); } Имеем право собирать первый массив?
26. 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"); } 26 Разминка Область видимости переменной arr1
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 Разминка Область видимости переменной arr1 Область жизни переменной arr1
28. 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"); } 28 Разминка Здесь GC имеет право собрать первый массив
29. 29 Разминка 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: ...
30. 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"); } 30 Разминка Интерпретатор не вычисляет время жизни!
31. 31 Разминка 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"); } Интерпретатор не вычисляет время жизни! (предполагает худший случай)
32. 32 История #1. Объекты-призраки
33. 33 История #1. Объекты-призраки Слабые ссылки:
34. 34 История #1. Объекты-призраки Слабые ссылки: 1. java.lang.ref.* 2. Не останавливают GC от сборки референта
35. 35 История #1. Объекты-призраки Слабые ссылки: 1. java.lang.ref.* 2. Не останавливают GC от сборки референта 3. «Протухают»
36. 36 История #1. Объекты-призраки Слабые ссылки: 1. java.lang.ref.* 2. Не останавливают GC от сборки референта 3. «Протухают»
37. 37 Пример public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
38. 38 Пример public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
39. 39 Пример public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
40. 40 Пример 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
41. 41 Пример 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
42. 42 Пример 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()); }
43. Но ведь это искусственный пример? 43 Объекты-призраки
44. Но ведь это искусственный пример? 44 Объекты-призраки 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
45. 45 Реальный пример private static ResourceBundle getBundleImpl(..., ClassLoader loader, ...) { ... CacheKey cacheKey = new CacheKey(baseName, locale, loader); ... // обращение к loader через cacheKey ... return bundle; }
46. 46 Реальный пример private static ResourceBundle getBundleImpl(..., ClassLoader loader, ...) { ... CacheKey cacheKey = new CacheKey(baseName, locale, loader); ... // обращение к loader через cacheKey ... return bundle; } Слабая ссылка Последнее использование
47. 47 Реальный пример ◦ JDK 1.8.0_181 ◦ java.util.ResourceBundle.getBundle(...) ◦ Для проявления: -Xcomp + итерации ◦ JDK-8209184
48. 48 Что с этим делать?
49. 49 Что с этим делать? ◦ Перед использованием проверять, что ссылка не протухла
50. 50 Что с этим делать? ◦ Перед использованием проверять, что ссылка не протухла ◦ Продлить жизнь объекта!
51. 51 Что с этим делать? public static void main(String[] args) { Object obj = new Object(); WeakReference ref = new WeakReference<>(obj); System.gc(); System.out.println(ref.get().hashCode()); }
52. 52 Что с этим делать? 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 ??? }
53. 53 Что с этим делать? 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 Что с этим делать? 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 ??? } Но какое именно использование добавить? Как убедить компилятор его не выкидывать?
55. 55 Использование ◦ Передать в метод ◦ Записать в поле
56. 56 Использование ◦ Передать в метод ◦ Записать в поле ◦ Reference.reachabilityFence(obj) Since Java 9
57. 57 Лечение 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 ??? }
58. 58 Лечение 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); }
59. 59 Лечение 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; }
60. Подумаешь, один пример! 60 Объекты-призраки
61. 61 Объекты-призраки JDK-8212178
62. 62 Объекты-призраки public static BufferAllocator getBufferAllocator() { SoftReference<BufferAllocator> bAllocatorRef = tlba.get(); if (bAllocatorRef == null || bAllocatorRef.get() == null) { bAllocatorRef = new SoftReference(new BufferAllocator()); tlba.set(bAllocatorRef); } return bAllocatorRef.get(); } com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator:
63. 63 Объекты-призраки public static BufferAllocator getBufferAllocator() { SoftReference<BufferAllocator> bAllocatorRef = tlba.get(); if (bAllocatorRef == null || bAllocatorRef.get() == null) { bAllocatorRef = new SoftReference(new BufferAllocator()); tlba.set(bAllocatorRef); } return bAllocatorRef.get(); } com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator:
64. 64 Выводы ◦ GC имеет право собрать объект после последнего использования ◦ Компилятор может выкидывать использования при оптимизации ◦ Reference.reachabilityFence для продления жизни объекта
65. 65 Ходячие объекты-мертвецы
66. 66 Ходячие объекты-мертвецы Обратная проблема: объекты мертвы, но GC за ними приходить не торопится.
67. 67 Ходячие объекты-мертвецы
68. 68 Ходячие объекты-мертвецы Memory Drag - память, которую GC «протаскивает» до следующей* сборки (характеристика алгоритма GC)
69. 69 Ходячие объекты-мертвецы Большой Memory Drag ⇒
70. 70 Ходячие объекты-мертвецы Большой Memory Drag ⇒ Много зомби-объектов ⇒
71. 71 Ходячие объекты-мертвецы Большой Memory Drag ⇒ Много зомби-объектов ⇒ Результат: ◦ Неожиданные OOM ◦ Проблемы с java.lang.ref
72. 72 История #2. F-reachables
73. 73 История #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic.
74. 74 История #2. F-reachables Object.finalize() JavaDoc in JDK 9+: The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs.
75. 75 История #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.
76. 76 История #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.
77. 77 История #2. F-reachables ➢ JDK 8 ㄧ 89 реализаций finalize()
78. 78 История #2. F-reachables ➢ JDK 8 ㄧ 89 реализаций finalize() ➢ JDK 9 ㄧ 87 реализаций (Object.finalize() is deprecated since 9)
79. 79 История #2. F-reachables ➢ JDK 8 ㄧ 89 реализаций finalize() ➢ JDK 9 ㄧ 87 реализаций (Object.finalize() is deprecated since 9) ➢ JDK 11 ㄧ 84 реализации
80. 80 История #2. F-reachables Объекты с нетривиальным finalize(): ◦ живут дольше
81. 81 История #2. F-reachables Java Threads Finalizer Thread
82. 82 История #2. F-reachables Java Threads Finalizer Thread STW GC Threads
83. 83 История #2. F-reachables Java Threads Finalizer Thread STW GC Threads finalize() выполнить не получится
84. 84 История #2. F-reachables Объекты с нетривиальным finalize(): ◦ живут дольше: для STW как минимум (!) на один цикл GC
85. 85 История #2. F-reachables class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
86. class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } } 86 История #2. F-reachables ref используется из finalize, значит он тоже выживет Foo ref
87. 87 История #2. F-reachables ref используется из finalize, значит он тоже выживет как и все достижимое из ref Foo ref class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
88. Объекты с нетривиальным finalize(): ◦ живут дольше: для STW как минимум (!) на один цикл GC ◦ дополнительно удерживают все достижимые из них объекты (f-reachables) 88 История #2. F-reachables
89. Как JVM может бороться с F-reachables? 89 JVM vs F-reachables
90. 90 JVM vs F-reachables Foo ref ... ... ... class Foo { Object ref; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
91. 91 JVM vs F-reachables Foo ref ... ... ... class Foo { Object ref; Object ref2; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
92. class Foo { Object ref; Object ref2; Foo(Object r) { ref = r; } void finalize() { ref.call(); } } Foo 92 JVM vs F-reachables ref ... ... ... ref2
93. Foo 93 JVM vs F-reachables ref ... ... ... ref2 но ref2 не используется в finalize! class Foo { Object ref; Object ref2; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
94. Foo 94 JVM vs F-reachables ref ... ... ... ref2 но ref2 не используется в finalize! можно сократить f-reachables (так делается в Excelsior JET) class Foo { Object ref; Object ref2; Foo(Object r) { ref = r; } void finalize() { ref.call(); } }
95. Как обнаружить проблему с F-reachables? 95 Developer vs F-reachables
96. Как обнаружить проблему с F-reachables? 96 Developer vs F-reachables jmap -finalizerinfo <PID>
97. Как обнаружить проблему с F-reachables? 97 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
98. Как обнаружить проблему с F-reachables? 98 Developer vs F-reachables jmap -finalizerinfo <PID> HotSpot-specific
99. Как обнаружить проблему с F-reachables? 99 Developer vs F-reachables jmap -finalizerinfo <PID> -Djet.gc.finalizer.stat HotSpot-specific
100. Как Вы можете бороться с F-reachables? 100 Developer vs F-reachables
101. 101 Developer vs F-reachables Foo ref1 ref2 ref3 resource1 resource2 resource3 finalize() Как Вы можете бороться с F-reachables?
102. 102 Developer vs F-reachables Foo ref1 ref2 ref3 resource1 resource2 resource3 State state finalize() Как Вы можете бороться с F-reachables?
103. Как Вы можете бороться с F-reachables? 103 Developer vs F-reachables
104. Если не finalize(), то кто? 104 Developer vs F-reachables
105. Если не finalize(), то кто? 105 Developer vs F-reachables java.lang.ref.Cleaner (ранее sun.misc.Cleaner)
106. 106 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()
107. 107 Developer vs F-reachables Поможет с Memory Drag только в Java 9+! JDK-8071507 Если не finalize(), то кто? java.lang.ref.Cleaner (ранее sun.misc.Cleaner)
108. 108 Выводы ◦ finalize() увеличивает Memory Drag ◦ JVM могут облегчить симптомы (но делают это редко) ◦ java.lang.ref.Cleaner since Java 9
109. 109 История #3. Непотизм GC Непотизм (кумовство) — вид фаворитизма, предоставляющий привилегии родственникам или друзьям независимо от их профессиональных качеств.
110. 110 Пример 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) { ... } } }
111. 111 Пример public void addLast(Node n) { final var l = last; last = n; if (l == null) { first = n; } else { l.next = n; } }
112. 112 Пример 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; } }
113. public void addLast(Node n) { final var l = last; last = n; if (l == null) { first = n; } else { l.next = n; } } 113 Пример public void removeFirst() { if (first != null) { var next = first.next; first = next; if (next == null) { last = null; } } }
114. 114 История #3. Непотизм Сборка мусора по поколениям: ◦ Молодое/старое поколения ◦ Minor/Major GC
115. 115 История #3. Непотизм Сборка мусора по поколениям: ◦ Молодое/старое поколения ◦ Minor/Major GC ◦ Все достижимое из старого поколения должно переживать Minor GC
116. 116 История #3. Непотизм Young Generation Old Generation
117. 117 История #3. Непотизм new DummyList() DummyList first last Young Generation Old Generation
118. 118 История #3. Непотизм DummyList first last Young Generation Old Generation
119. 119 История #3. Непотизм DummyList first last Young Generation Old Generation
120. 120 История #3. Непотизм DummyList first last DummyList.addLast(...) Young Generation Old Generation
121. 121 История #3. Непотизм DummyList first last DummyList.addLast(...) Young Generation Old Generation
122. 122 История #3. Непотизм DummyList first last DummyList.addLast(...) Young Generation Old Generation
123. 123 История #3. Непотизм DummyList first last Young Generation Old Generation
124. 124 История #3. Непотизм DummyList first last Young Generation Old Generation
125. 125 История #3. Непотизм DummyList first last DummyList.removeFirst(...) Young Generation Old Generation
126. 126 История #3. Непотизм DummyList first last DummyList.removeFirst(...) Young Generation Old Generation
127. 127 История #3. Непотизм DummyList first last Young Generation Old Generation
128. 128 История #3. Непотизм DummyList first last Young Generation Old Generation
129. 129 История #3. Непотизм Сборка мусора по поколениям сознательно увеличивает Memory Drag.
130. 130 История #3. Непотизм Сборка мусора по поколениям сознательно увеличивает Memory Drag. Старое поколение - источник ходячих мертвецов
131. 131 История #3. Непотизм Но ведь это искусственный пример?
132. 132 История #3. Непотизм Но ведь это искусственный пример? Tony Printezis о борьбе с непотизмом LinkedHashMap в TwitterJDK: https://youtu.be/M9o1LVfGp2A?t=1391
133. 133 Как обнаружить непотизм?
134. 134 Как обнаружить непотизм? По косвенным признакам: 1. Частые и долгие Full GC (проверить по -XX:+PrintGCDetails) 2. Много подозрительных живых объектов (смотреть jmap -dump <PID>)
135. 135 Что делать?
136. 136 Что делать? ◦ Ждать Full GC
137. 137 Что делать? ◦ Ждать Full GC ◦ Занулять ссылки из объектов при удалении
138. 138 /** * 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: Что делать?
139. /** * 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 ... } 139 java.util.LinkedList: Что делать?
140. 140 Что делать? void afterNodeRemoval(Node<K,V> e) { // unlink LinkedHashMap.Entry<K,V> p = (LinkedHashMap.Entry<K,V>)e; b = p.before, a = p.after; p.before = p.after = null; ... } java.util.LinkedHashMap:
141. 141 Что делать? ◦ Ждать Full GC ◦ Занулять ссылки из объектов при удалении
142. 142 Что делать? ◦ Ждать Full GC ◦ Занулять ссылки из объектов при удалении ◦ Увеличить размер молодого поколения -Xmn -XX:NewRatio -XX:NewSize
143. 143 Ходячие объекты-мертвецы А может ли GC вообще не прийти за мертвым объектом?
144. 144 Ходячие объекты-мертвецы
145. 145 История #4. Консерватизм
146. 146 Точный 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"); }
147. 147 Точный 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"); } Как GC понимает, какие локалы живы?
148. 148 Точный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
149. 149 Точный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
150. 150 Точный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
151. 151 Точный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
152. 152 Точный GC ➢ Поддержка от компилятора
153. 153 Точный GC ➢ Поддержка от компилятора ➢ Генерация карт стека и регистров
154. 154 Точный GC ➢ Поддержка от компилятора ➢ Генерация карт стека и регистров ➢ Карты только в safe-points!
155. 155 Консервативный GC А нельзя ли без поддержки от компилятора?
156. 156 Консервативный GC ➢ Предполагаем худшее: каждое значение может быть указателем ➢ Отсеиваем лишнее в рантайме
157. 157 Консервативный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
158. 158 Консервативный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
159. 159 Консервативный GC stack sp+30h sp+0h registers rax rcx ... rdx r14
160. 160 Консервативный GC ➢ Предполагаем худшее: каждое значение может быть указателем ➢ Отсеиваем лишнее в рантайме ➢ Иногда ошибаемся ⇒ увеличиваем Memory Drag на величину ошибки
161. 161 Консервативный GC Зачем такое нужно?
162. 162 Консервативный GC Зачем такое нужно? ➢ Нет карт ⇒ они не занимают место ➢ Нет карт ⇒ нет затрат на генерацию
163. 163 Консервативный GC Зачем такое нужно? ➢ Нет карт ⇒ они не занимают место ➢ Нет карт ⇒ нет затрат на генерацию ➢ Нет карт ⇒ можно выкинуть safe-points
164. 164 Safe-points 1 - 2 машинные инструкции Обратные дуги циклов и эпилоги
165. 165 Safe-points 1 - 2 машинные инструкции Обратные дуги циклов и эпилоги Ухудшают производительность ⇒ Агрессивно оптимизируются
166. 166 Мир без safe-points
167. 167 Мир без safe-points Производительность растет Размер кода уменьшается
168. 168 Мир без safe-points Производительность растет Размер кода уменьшается Многое работает через safe-points, поэтому потребует переработки
169. 169 Консервативный GC А так вообще делают?
170. 170 Консервативный GC А так вообще делают? Теория: Boehm GC, 1988, conservative Immix, 2008, mostly-precise
171. 171 Консервативный GC А так вообще делают? Теория: Boehm GC, 1988, conservative Immix, 2008, mostly-precise Практика:
172. 172 Консервативный GC А так вообще делают? Теория: Boehm GC, 1988, conservative Immix, 2008, mostly-precise Практика: MobiVM
173. 173 Консервативный GC А так вообще делают? Теория: Boehm GC, 1988, conservative Immix, 2008, mostly-precise Практика: MobiVM scala-native
174. 174 Консервативный GC А так вообще делают? Теория: Boehm GC, 1988, conservative Immix, 2008, mostly-precise Практика: MobiVM scala-native Excelsior JET (с 1999 по 2015)
175. 175 Неограниченный Memory Drag Консервативная ошибка: ◦ обычно продлевает жизнь объекта на один или несколько циклов GC (пока ложный корень на стеке)
176. 176 Неограниченный Memory Drag Консервативная ошибка: ◦ обычно продлевает жизнь объекта на один или несколько циклов GC (пока ложный корень на стеке) ◦ иногда продлевает навсегда
177. 177 Неограниченный Memory Drag public class Executor extends Thread { public abstract class Task implements Runnable { } final TaskQueue queue = new TaskQueue(); . . . }
178. 178 Неограниченный Memory Drag public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } }
179. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 179 Неограниченный Memory Drag stack sp+20h addr t
180. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 180 Неограниченный Memory Drag stack addr t sp+20h
181. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 181 Неограниченный Memory Drag stack addr t sp+20h
182. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 182 Неограниченный Memory Drag stack addr t sp+20h
183. 183 Неограниченный Memory Drag Может это искусственный пример?
184. 184 Неограниченный Memory Drag Может это искусственный пример? Нет, это класс java.util.Timer из JDK И там все еще хуже
185. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 185 Неограниченный Memory Drag stack addr t sp+20h
186. public void mainLoop() { while (true) { synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } Task t = queue.get(); t.run(); } } } 186 Неограниченный Memory Drag stack addr t sp+20h threadReaper
187. 187 Неограниченный Memory Drag Как Вы можете бороться с консервой?
188. 188 Неограниченный Memory Drag Как Вы можете бороться с консервой?
189. 189 Неограниченный Memory Drag Как Вы можете бороться с консервой?
190. 190 Неограниченный Memory Drag 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.
191. 191 Выводы Консервативный GC - большая сила, но и большая ответственность
192. 192 Выводы Консервативный GC - большая сила, но и большая ответственность Консерва не только в GC (смотри первый пример)
193. 193 Заключение
194. 194 Заключение Не нужно пытаться предугадать время жизни объекта и рассчитывать на это в коде!
195. 195 Заключение Не нужно пытаться предугадать время жизни объекта и рассчитывать на это в коде! Если вы все-таки на это решились: Используйте правильные костыли решения (reachabilityFence, Cleaner, Timer.cancel)
196. 196 Q & A iugliansky@excelsior-usa.com @dbg_nsk www.excelsiorjet.com/blog