Garbage collection in V8 engine (RU slides)

Transcript

1. Garbage collection in V8 VM 1
2. Кто я такой? 2
3. Кто я такой? • Студент факультета кибернетики КНУ им. Шевченка. 2
4. Кто я такой? • Студент факультета кибернетики КНУ им. Шевченка. • Пишу на C++, Java/Scala/Kotlin(JVM) и JS(V8). 2
5. Кто я такой? • Студент факультета кибернетики КНУ им. Шевченка. • Пишу на C++, Java/Scala/Kotlin(JVM) и JS(V8). • Люблю копаться в движках и писать фронтенд. 2
6. Кто я такой? • Студент факультета кибернетики КНУ им. Шевченка. • Пишу на C++, Java/Scala/Kotlin(JVM) и JS(V8). • Люблю копаться в движках и писать фронтенд. • Компиляторов, если что. 2
8. Вся мудрость тут 㱺
9. Вся мудрость тут 㱺 Все основные алгоритмы GC пользуют наработки этой книги
11. GC в V8 5
12. GC в V8 • Как и во всех виртуальных машинах, существует система управления памятью : 5
13. GC в V8 • Как и во всех виртуальных машинах, существует система управления памятью : • Аллокатор. 5
14. GC в V8 • Как и во всех виртуальных машинах, существует система управления памятью : • Аллокатор. • Сборщик мусора (он же GC). 5
15. Модель памяти в JS (V8) 6
16. Модель памяти в JS (V8) 6 • Отдельно представлены целые числа на стеке
17. Модель памяти в JS (V8) 6 • Все остальные объекты, аллоцирующиеся в хипе, неявно наследуются от HeapObject. • Все объекты выровнены на 4 байта. • Отдельно представлены целые числа на стеке
18. Как устроен Heap 7
19. Как устроен Heap • New Space (aka YoungGen): Большинство объектов живут именно здесь. Умирают тоже. 7
20. Как устроен Heap • New Space (aka YoungGen): Большинство объектов живут именно здесь. Умирают тоже. • Old Space (aka OldGen) : Объекты, пережившие одну и больше фаз сборки. 7
21. Как устроен Heap • New Space (aka YoungGen): Большинство объектов живут именно здесь. Умирают тоже. • Old Space (aka OldGen) : Объекты, пережившие одну и больше фаз сборки. • Code Space: Здесь размещаются объекты кода, содержащие инструкции JIT-компилятора. Это единственное пространство с исполняемой памятью. 7
22. Слабая гипотеза о поколениях 8
23. Слабая гипотеза о поколениях • Объекты чаще всего не переживают следующей сборки после их рождения. 8
24. Слабая гипотеза о поколениях • Объекты чаще всего не переживают следующей сборки после их рождения. • Объекты чаще всего умирают молодыми. 8
26. Внезапная польза 10
27. Внезапная польза • Подобная гипотеза, подтвержденная частыми наблюдениями (не только в V8), позволяет разработчикам виртуальных машин делать некоторые спекулятивные операции. 10
28. Внезапная польза • Подобная гипотеза, подтвержденная частыми наблюдениями (не только в V8), позволяет разработчикам виртуальных машин делать некоторые спекулятивные операции. • А именно - разделять сборки в регионах хипа, и разрабатывать разные алгоритмы для них. 10
29. Подходы к сборке 11
30. Подходы к сборке • Stop-the-world (город main-thread приложения засыпает, GC работает, после окончания приложение опять просыпается). 11
31. Подходы к сборке • Stop-the-world (город main-thread приложения засыпает, GC работает, после окончания приложение опять просыпается). • Concurrent (сборщик (частями) работает параллельно с приложением). 11
32. Подходы к сборке • Stop-the-world (город main-thread приложения засыпает, GC работает, после окончания приложение опять просыпается). • Concurrent (сборщик (частями) работает параллельно с приложением). • Важно : конкурентными могут быть несколько из фаз сборки! 11
33. Стратегии сборки 12
34. Стратегии сборки Всего существует аж 3 стратегии сборки мусора : 12
35. Стратегии сборки Всего существует аж 3 стратегии сборки мусора : • No operations: считаем все объекты мусором, и творим тотальный экстерминатус всем обитателям хипа, вырубая работающую VM. 12
36. Стратегии сборки Всего существует аж 3 стратегии сборки мусора : • No operations: считаем все объекты мусором, и творим тотальный экстерминатус всем обитателям хипа, вырубая работающую VM. • Mark-Sweep/Compact: помечаем все живые объекты, удаляем недостижимые (и делаем перемещение живых регионов). 12
37. Стратегии сборки Всего существует аж 3 стратегии сборки мусора : • No operations: считаем все объекты мусором, и творим тотальный экстерминатус всем обитателям хипа, вырубая работающую VM. • Mark-Sweep/Compact: помечаем все живые объекты, удаляем недостижимые (и делаем перемещение живых регионов). • Pointer counting: присобачиваем к каждому объекту счетчик ссылок на него и удаляем его, когда счетчик равен нулю. 12
38. Немного недоумения 13
39. Немного недоумения • Вообще-то, настоящим, на мой вкус, сборщиком мусора, является подход с подсчетом ссылок. 13
40. Немного недоумения • Вообще-то, настоящим, на мой вкус, сборщиком мусора, является подход с подсчетом ссылок. • В Mark-* мы помечаем и перемещаем достижимые объекты, а не мусор! 13
41. Сборка в YoungGen 14
42. Сборка в YoungGen • Два субрегиона : «From Space» и «To Space» 14
43. Сборка в YoungGen • Два субрегиона : «From Space» и «To Space» • «From Space» изначально пустой. 14
44. Сборка в YoungGen • Два субрегиона : «From Space» и «To Space» • «From Space» изначально пустой. • К GC прилетел сигнал, что в «To Space» переполнение. 14
45. Сборка в YoungGen • Два субрегиона : «From Space» и «To Space» • «From Space» изначально пустой. • К GC прилетел сигнал, что в «To Space» переполнение. • Также существует специальный Pointer Map на все объекты из Young Generation. 14
46. Scavenger, Part 1 15
47. Scavenger, Part 1 15
48. Scavenger, Part 1 1. To Space переполнился*, GC начинает работу. 15
49. Scavenger, Part 1 1. To Space переполнился*, GC начинает работу. 2. To Space и From Space обмениваются своим содержимым. 15
50. Scavenger, Part 2 16
51. Scavenger, Part 2 16
52. Scavenger, Part 2 3. Проходимся линейно по From Space, помечаем живые объекты. 16
53. Scavenger, Part 2 3. Проходимся линейно по From Space, помечаем живые объекты. 4. Перемещаем живые объекты в To Space, удаляем лишнее из From Space. 16
54. Scavenger, Part 2 3. Проходимся линейно по From Space, помечаем живые объекты. 4. Перемещаем живые объекты в To Space, удаляем лишнее из From Space. 5. To Space отдает эти данные в OldGen. 16
55. Сборка в OldGen 17
56. Сборка в OldGen Сборка в OldGen является классическим алгоритмом Mark-Compact: 17
57. Сборка в OldGen Сборка в OldGen является классическим алгоритмом Mark-Compact: 1. Сначала, начиная из rootset, проходимся по всему графу объектов и помечаем достижимые. (Mark*) 17
58. Сборка в OldGen Сборка в OldGen является классическим алгоритмом Mark-Compact: 1. Сначала, начиная из rootset, проходимся по всему графу объектов и помечаем достижимые. (Mark*) 2. Чистим хип. (Sweep) 17
59. Сборка в OldGen Сборка в OldGen является классическим алгоритмом Mark-Compact: 1. Сначала, начиная из rootset, проходимся по всему графу объектов и помечаем достижимые. (Mark*) 2. Чистим хип. (Sweep) 3. Сжимаем хип. (Compact) 17
60. Стадия : Mark 18
61. Стадия : Mark Алгоритм маркировки представляет собой (главным образом) обход графа в глубину с использованием стека и трехцветной абстракцией : 18
62. Стадия : Mark Алгоритм маркировки представляет собой (главным образом) обход графа в глубину с использованием стека и трехцветной абстракцией : • Черные - вершины с посещенными и просканированными ссылками. 18
63. Стадия : Mark Алгоритм маркировки представляет собой (главным образом) обход графа в глубину с использованием стека и трехцветной абстракцией : • Черные - вершины с посещенными и просканированными ссылками. • Серые - посещенные вершины с непросмотренными ссылками. 18
64. Стадия : Mark Алгоритм маркировки представляет собой (главным образом) обход графа в глубину с использованием стека и трехцветной абстракцией : • Черные - вершины с посещенными и просканированными ссылками. • Серые - посещенные вершины с непросмотренными ссылками. • Белые - непосещенные вершины. 18
65. Стадия : Mark Алгоритм маркировки представляет собой (главным образом) обход графа в глубину с использованием стека и трехцветной абстракцией : • Черные - вершины с посещенными и просканированными ссылками. • Серые - посещенные вершины с непросмотренными ссылками. • Белые - непосещенные вершины. Используется стек указателей, а не рекурсия. (Привет, StackOverflow), и им является From Space из YoungGen. 18
66. STW Mark 19
67. STW Mark 20
68. STW Mark 21
69. STW Mark 22
70. STW Mark 23
71. STW Mark 24
72. STW Mark 25
73. STW Mark 26
74. STW Mark 27
75. STW Mark 28
76. STW Mark 29
77. STW Mark 30
78. Incremental Mark 31
79. Incremental Mark 31 • Начинается, когда куча становится больше некоего порогового значения, а не заполняется.
80. Incremental Mark 31 • Начинается, когда куча становится больше некоего порогового значения, а не заполняется. • Пауз становится больше, но они становятся короче.
81. Incremental Mark 31 • Начинается, когда куча становится больше некоего порогового значения, а не заполняется. • Пауз становится больше, но они становятся короче. • За паузу сканируется часть хипа.
82. Incremental Mark 31 • Начинается, когда куча становится больше некоего порогового значения, а не заполняется. • Пауз становится больше, но они становятся короче. • За паузу сканируется часть хипа. • Но взамен на эту всю красоту появляются проблемы с консистентностью графа объектов.
83. 32 Incremental Mark : трабла раз Аллоцирование нового объекта в черном объекте / указание ссылки на «мусорный» объект.
84. 33 Incremental Mark : трабла два Удаление ссылки на черный объект.
85. Write Barriers уже выехали!
86. 35 Write Barriers
87. 35 Write Barriers • Существует специальный буфер, в который помещаются перехваченные записи в хип.
88. 35 Write Barriers • Существует специальный буфер, в который помещаются перехваченные записи в хип. • Удаления при этом обрабатываются. 
 То есть, удаленные ссылки не считаются удаленными до конца текущей раскраски объектов. После они спокойно удаляются.
89. 36 Порешаем траблы Оставляем удаленную ссылку
90. 37 Порешаем траблы А давайте-ка покрасим родителя зеленой ссылки в серый, и снова пройдемся по его дочерним объектам и ссылкам. ОПЯТЬ РАБОТАТЬ?
91. 38 Порешаем траблы А давайте-ка покрасим родителя зеленой ссылки в серый, и снова пройдемся по его дочерним объектам и ссылкам.
92. 39 Порешаем траблы А давайте-ка покрасим родителя зеленой ссылки в серый, и снова пройдемся по его дочерним объектам и ссылкам.
93. 40 Порешаем траблы А давайте-ка покрасим родителя зеленой ссылки в серый, и снова пройдемся по его дочерним объектам и ссылкам.
94. 41 Порешаем траблы Готово! 
 И да, это не настолько дорого, как Вы подумали.
 Эвристики нам в помощь :)
95. Стадия : Sweep 42
96. Стадия : Sweep • Sweep чрезвычайно прост: он просто выполняет линейный поиск мёртвых объекты в каждой странице хипа, очищает память, и передает ее в специальный список свободной памяти. 42
97. Стадия : Sweep 43
98. Стадия : Sweep • В каждой странице хранятся отдельные списки свободной памяти для небольших регионов (< 2^8 слов), средние регионы (< 2^11 слов), большие регионы (< 2^14 слова) и огромные регионы. 43
99. Стадия : Sweep • В каждой странице хранятся отдельные списки свободной памяти для небольших регионов (< 2^8 слов), средние регионы (< 2^11 слов), большие регионы (< 2^14 слова) и огромные регионы. • Свободные списки в основном используются алгоритмом Scavenge для перемещения выживших объектов в OldGen, a также используются алгоритмом уплотнения для перемещения объектов. 43
100. Sweep наглядно 44 Фаза первая. Произошел GC reason.
 Хип не помаркан – маркаем.
101. Sweep наглядно 45 Фаза вторая. Mark отработал, хип размечен.
102. Sweep наглядно 46 Фаза третья. В каждом регионе sweeper удалил объекты и отдал память под повторную аллокацию.
103. Parallel Sweep 47
104. Parallel Sweep • Так как хип размечен по регионам, выделить N-ное количество потоков на уборку этих самых регионов не составляет труда. 47
105. Parallel Sweep • Так как хип размечен по регионам, выделить N-ное количество потоков на уборку этих самых регионов не составляет труда. • Время паузы при этом заметно сокращается. 47
106. Стадия : Compact 48
107. Стадия : Compact • Самая сложная, на мой вкус, функция сборщика мусора. 48
108. Стадия : Compact • Самая сложная, на мой вкус, функция сборщика мусора. • Главная проблема здесь - обеспечить дефрагментацию страниц. 48
109. Стадия : Compact • Самая сложная, на мой вкус, функция сборщика мусора. • Главная проблема здесь - обеспечить дефрагментацию страниц. • Порождает N-нное количество головняка у разработчиков GC. 48
110. Как справился Google?
111. Как справился Google? • Google может выдохнуть, так как на самом деле JS не является многопоточным, и большое количество нюансов, которые надо предусмотреть в многопоточной среде языка, исчезают. • Но перенос внутри VM все равно происходит в критической секции.
112. Compact крупно 50
113. Compact крупно • Compact переносит объекты из фрагментированных регионов (содержащих много небольших свободных пространств) в свободные места на других регионах. 50
114. Compact крупно • Compact переносит объекты из фрагментированных регионов (содержащих много небольших свободных пространств) в свободные места на других регионах. • Для каждого живого объекта в эвакуируемом регионе выделяется место из списка свободной памяти другой страницы. 50
115. Compact крупно • Compact переносит объекты из фрагментированных регионов (содержащих много небольших свободных пространств) в свободные места на других регионах. • Для каждого живого объекта в эвакуируемом регионе выделяется место из списка свободной памяти другой страницы. • Каждый объект копируется в выделенное место, а в еще не удаленном объекте появляется так называемый «forwarding pointer», указывающий на настоящий объект. 50
116. Как Compact работает 51
117. Как Compact работает 51
118. Как Compact работает 51 Фаза раз : Есть фрагментированный хип. 
 Сожмем?
119. Как Compact работает 52
120. Как Compact работает 52
121. Как Compact работает 52 Фаза два-с. Размечаем фрагментированные регионы. Определяем для каждого объекта его новое место.
122. Перенос 53
123. Перенос 54
124. Перенос 55
125. Перенос 56
126. Compact работу закончил! 57
127. Compact работу закончил! 57 Готово!
128. Compact работу закончил! 57 Готово!
129. Перенос объектов 58
130. Перенос объектов 59 Как только эвакуация завершена, V8 выполняет итерацию по списку записанных мест указателя и обновляет их, указывая на новые копии.
131. Перенос завершён! 60
132. Compact молодец! 61
133. Compact молодец! 61
134. После уборки 62
135. После уборки • Все объекты снова маркируются как «белые». • GC прибирается в кэшах и деоптимизрует отмеченные для деоптимизиации объекты. • Отпускает паузу. 62
136. Выводы 63
137. Выводы • Гуглу удалось создать коллектор, который балансирует между средним временем паузы и оверхэдом на сборку. При этом разработчики (большинство) довольны, так как у них не возникает с ним проблем. • Если уж приложение и тормозит, то вам стоит покопаться в собственном коде и посмотреть на вкладку «Performance», и проверить, а поэтому ли тормозит? • Если да, то попросить приложение меньше мусорить. 63
138. Q/A? 64