Your SlideShare is downloading. ×
Cборка мусора в Java без пауз  (HighLoad++ 2013)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cборка мусора в Java без пауз (HighLoad++ 2013)

2,812

Published on

Доклад про паузы при сборке мусора уже был на одной из прошлых конференций HighLoad++. …

Доклад про паузы при сборке мусора уже был на одной из прошлых конференций HighLoad++.
Паузы stop-the-world являются неотъемлемым атрибутом автоматического управления памятью.
Или всё-таки их можно избежать? – Можно!
Алгоритмы, не требующие пауз для управления памятью, существуют. Существуют и реальные JVM, которые их реализуют.

Содержание доклада
- Принципы автоматического управления памятью (сборки мусора).
- "Метроном" - классический алгоритм сборки мусора без пауз.
- С4 - алгоритм сборки мусора Zing JVM (Azul Systems).
- Особенности эффективной реализации на x86-архитектуре.
- Дополнительные источники проблем: слабые ссылки, фрагментация и прочее.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,812
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
23
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Сборка мусора в Java без пауз Алексей Рагозин
  • 2. Сборка мусора Mark-Sweep  Фаза 1 – маркировка достижимых объектов  Фаза 2 – “вычистка” мусора Copy collector (сборка копированием)  Использует две области памяти, но выполняется в один проход Mark-Sweep-Compact  Mark-Sweep + перемещение живых объектов
  • 3. Барьеры Барьеры – специальные процедуры, выполняемые VM при каждом обращении к памяти. Барьер на запись – при записи указателя в память. Барьер на чтение – при чтении указателя из памяти. JIT компиляция позволяет частично сократить нагрузку барьеров за счёт глобальной оптимизации.
  • 4. Карточный барьер Program Memory Dirty cards 0xABCD1200 entry.next = y; mark card write memory 0xABCD1200 table[n] = entry; mark card write memory 0xABCD1800  На каждые N байт памяти – флаг в таблице карт  Любая запись указателя в память, взводит флаг 0xABCD1400 0xABCD1600 0xABCD1400 0xABCD1600
  • 5. roots Фоновая маркировка
  • 6. roots Фоновая маркировка
  • 7. roots Фоновая маркировка
  • 8. roots Фоновая маркировка
  • 9. roots Фоновая маркировка
  • 10. roots Фоновая маркировка
  • 11. Карточный барьер на запись Фоновая маркировка с карточным барьером на запись требует 2ух коротких пауз. Так же, барьер на запись не позволяет реализовать фоновое перемещение объектов. Можно ли придумать лучший алгоритм, используя барьер на чтение?
  • 12. roots Сборка копированием FROM TO
  • 13. roots Сборка копированием FROM TO
  • 14. roots Сборка копированием FROM TO 1
  • 15. roots Сборка копированием FROM TO 1 2
  • 16. roots Сборка копированием FROM TO 1 2
  • 17. roots Сборка копированием FROM TO 3 1 2
  • 18. Алгоритм метроном Алгоритм основан на сборке копированием. В течение сборки каждый прикладной поток  При чтении указателя, каждый поток проверяет какой области он принадлежит  Если адрес принадлежит “from” пространству, поток выполняет нерекурсивное копирование объекта в “to” и корректирует адрес.  Продлжает работу
  • 19. Метроном roots GC thread Application thread V1 FROM TO 1
  • 20. Метроном roots GC thread Application thread V1 FROM TO 1
  • 21. Метроном roots GC thread Application thread V1 FROM TO 1 2
  • 22. Метроном roots GC thread Application thread V1 FROM TO 1 2
  • 23. Метроном roots GC thread Application thread V1 FROM TO 1 3 2
  • 24. Метроном roots GC thread Application thread V1 FROM TO 4 1 3 2
  • 25. Метроном roots GC thread Application thread V1 FROM TO 4 1 3 2
  • 26. На пути к решению • Стоимость барьера на чтение • Время копирования объекта  Например, большого массива • Атомарное обнуление слабых ссылок • Стоимость сборки мусора  Generational vs single spaced
  • 27. Azul Vega – Java суперкомпьтер 2007 – Vega 2, 7200 series  up to 768 cores  768 GiB RAM  SPARC микорархитектура  hardware assisted garbage collection
  • 28. LVB - барьер на загрузку указателя Load Value Barrier • Срабатывает при загрузке указателя из памяти в регистр • При срабатывании барьера происходит коррекция источника в памяти • Прикладной код работает только с проверенными указателями • При изменении правил барьера потоки ревалидируют указатели в регистрах
  • 29. Azul JVM Таблица LVB триггеров 64 битный адрес (хранимый в памяти) LVB tag Flags Page Offset 64 0 Адрес в памяти
  • 30. Azul JVM Доступ в память не требует арифметики указателей CPU спекулятивно выполняет код параллельно с проверкой барьера Проверка барьера одним условием Допольнительные биты используются в процессе маркировки и для работы со слабыми ссылками
  • 31. Azul JVM C4 (Continuously Concurrent Compacting Collector)  Инкрементальная сборка мусора регионами  Алгоритм сборки копированием  Барьер на чтение обеспечивает фоновую сборку  Generational  Регионы классифицируюся как молодые и старые  Фоновая маркировка для оценки “замусоренности” региона С4 не является алгоритмом реального времени
  • 32. Azul JVM http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf
  • 33. Azul JVM Mark – фоновая маркировка для выбора регионов подлежащих сборке. Relocate – копирования объектов. Remap – рекурсивный обход графа и коррекция ссылок. Молодые сборки проходят параллельно инкрементальных и включают только relocate фазу.
  • 34. Azul JVM 2010 Zing 4.0 – virtual appliance 2011 Zing 5.0  x86 (64 бит) архитектура  Linux Механизм виртуальной памяти используется для эмулации “незначащих” битов адреса.
  • 35. Azul JVM 3 стратегии копирования  до 256 Kb – копирование байт между страницами  256 Kb – 16 Mb – перемещаются 4k страницы виртуальной памяти с последующей дефрагментацией  Более 16 Mb – не перемещаются 2M страницы виртуальной памяти
  • 36. Без пауз ≠ Без проблем “Безпаузный” алгоритм не спасет от  утечек памяти  неправильного сайзинга памяти JVM  свопинга  псевдо-свопинга (ожидания записи дискового кэша)  кривых рук (хотя существенно снижает риск)
  • 37. Спасибо Алексей Рагозин (alexey.ragozin@gmail.com) http://blog.ragozin.info http://aragozin.timepad.ru

×