почему у сборщиков мусора такая пауза вообще?
GC работают путем отслеживания достижимых блоков кучи, начиная с набора глобальных корней (глобальные переменные,
стеки потоков и регистры процессора). ГК лежат на скользящей шкале от снимка до «на лету».
Снимки GC работают на основе снимка глобальных корней и топологии кучи. ГХ на лету
постепенно обновляйте свою интерпретацию кучи по мере запуска мутаторов.
Трассировка - это не «почему у сборщиков мусора такая пауза вообще», есть более веские причины для остановки: перемещение объекта является доминирующим.
Но в отношении трассировщиков моментальных снимков и их относительной эффективности: трассировка на лету может быть более эффективной, чем трассировщики моментальных снимков. В той же статье, на которую вы ссылаетесь при описании [VCGC], предыдущий коллектор Pauseless, созданный Азулом, классифицируется как точный индикатор волнового фронта [3]:
"... Большинство практических сборщиков используют консервативные абстракции волнового фронта, а не точное определение, приведенное здесь. То есть волновой фронт отслеживается при детализации объекта. Однако точный волновой фронт не просто теоретический и недавно использовался в аппаратном сборщике для Java-сервера Azul, у которого в каждом указателе есть бит «не отмечен» [2]. "
Azul C4 разделяет это качество, но достигает его, используя чисто программный, самовосстанавливающийся барьер чтения LVB.
ГХ с полностью моментальными снимками достигают высокой пропускной способности, поскольку сборщик работает почти полностью
независимо от мутаторов, но имеют большую задержку, потому что создание снимка вызывает паузу.
ГХ полностью на лету достигают низкой задержки, потому что все делается постепенно, но с низкой
пропускная способность из-за мелкозернистой связи между мутаторами и GC.
Точный трассировщик волнового фронта столь же эффективен (с точки зрения «не тратить время на ненужные объекты», обсуждаемый в статье), как трассировщик «останови мир», который по определению также имеет скрытый волновой фронт. По сравнению с подходами, основанными на снимках, точное сканирование волнового фронта никоим образом не снижает пропускную способность и не требует дополнительной связи между коллектором и мутатором. Он имеет пропускную способность «лучше или лучше», поскольку его точность гарантирует, что ему никогда не придется повторять какую-либо работу по отслеживанию.
почему у Азула нет такой проблемы?
У них все еще есть эта проблема, но они уменьшили ее, внедрив аппаратный барьер для чтения.
Ранее были предложены барьеры чтения, но программные барьеры чтения слишком сильно снижают пропускную способность.
потому что чтение указателей встречается гораздо чаще, чем запись.
Как уже отмечалось, если «проблема» заключалась в неэффективности из-за поведения «на лету» и «моментального снимка», то у C4 его нет, потому что он является точным индикатором волнового фронта. Более того, сборщик Azul C4 не нуждается в аппаратном барьере чтения и не использует его, поскольку он работает на системах vanilla x86 и Linux и обеспечивает лучшую пропускную способность на этом оборудовании, чем сборщики трассировки на основе снимков (см. Сравнение пропускной способности в [1]). .
Однако «проблема» в вопросе была сформулирована как «почему сборщики мусора вообще делают такую паузу?» Точность волнового фронта (или нет) мало что делает для доминирующих пауз в сборщиках мусора. Параллельные и в основном параллельные (даже если они менее эффективны, чем С4) маркеры существуют, но их сборщики все еще останавливаются. Проблема в том, что отслеживание является лишь частью коллекции. Трассировка только говорит вам, что живо и где это. Он не возвращает вам память и, конечно, не фрагментирует фрагментированную память. Эта тема подробно обсуждается в различных научных статьях (см. Множество ссылок из статьи C4 [1]).
Именно сжатие (и подразумеваемое перемещение объектов), кажется, является ахиллесовой пятой в настоящее время доставки сборщиков на серверные JVM, и вещь, которая по своей сути заставляет их делать [большие] паузы. Простой акт перемещения даже одного объекта из одного места в другое означает, что вам нужно исправить все ссылки, указывающие на этот объект, прежде чем программа их использует. Для большинства коммерческих сборщиков это означает паузу «остановка мира», которая не позволяет приложению работать во время исправления ссылок.
C4 использует самовосстанавливающийся LVB-барьер (новый тип барьера чтения, введенный в [2] и широко используемый в [1] только в программной форме), чтобы избежать необходимости исправления ссылок до того, как приложению будет разрешено работать. Вот как это позволяет избежать паузы, которую другие коллекционеры в конечном итоге должны принять. Качество самовосстановления снижает динамические затраты на барьеры чтения на несколько порядков по сравнению с предыдущими барьерами, не являющимися самовосстанавливающимися (такими как барьер типа Брукса, используемый в других параллельных компакторах в научных работах и в некоторых реальных время коллекционеров). Результатом этой значительно более низкой стоимости чтения-барьера является то, что он практичен для использования при сборе поколений и в JVM серверного масштаба.
[1]: «C4: коллектор непрерывного уплотнения» http://dl.acm.org/citation.cfm?id=1993491&dl=ACM&coll=DL&CFID=85063603&CFTOKEN=84074207
[2]: «Алгоритм GC без пауз» http://static.usenix.org/events/vee05/full_papers/p46-click.pdf
[3]: «Сохранение правильности параллельных алгоритмов сбора мусора» www.srl.inf.ethz.ch/papers/pldi06-cgc.pdf
(Грэм Томас, технический менеджер EMEA, Azul Systems)