Почему нет более бесстрастных ГК?

Все GC, которые я знаю, кроме Azul, несколько параллельны, но имеют хотя бы небольшой компонент stop-the-world. Почему нет большего количества GC, таких как Azul?

Разве Азул запатентовал свою технологию настолько, насколько это невозможно?

Или барьеры для чтения/записи, необходимые для беспроблемной работы, несут слишком много накладных расходов, что они непрактичны для большинства рабочих нагрузок?

Ответы

Ответ 1

ZGC

Начиная с Java 11, для Linux/x64 JDK доступен новый Z Garbage Collector (ZGC):

Z Garbage Collector, также известный как ZGC, - это масштабируемый сборщик мусора с малой задержкой, разработанный для решения следующих задач:

  • Время паузы не превышает 10 мс
  • Время паузы не увеличивается с размером кучи или установленного значения
  • Обрабатывать кучи размером от нескольких сотен мегабайт до нескольких терабайт

Вы можете включить ZGC, указав следующие аргументы JVM:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

Шенандоа GC

Кроме того, начиная с Java 12, имеется Shenandoah GC, доступный для всех платформ. ShenandoahGC имеет те же характеристики, что и ZGC, но его реализация отличается.

Ответ 2

Основываясь на документе Azul на C4, похоже, что C4 - это очень новая технология, реализация алгоритма, опубликованного в 2005 году, сначала на специализированном оборудовании, а затем портирована специально для Linux на x86, а реализация JVM находится очень близко к ядру VM.

Поскольку OpenJDK/HotSpot широко используется на нескольких платформах и в крупных производственных нагрузках, он имеет тенденцию двигаться медленнее при принятии крупных инноваций в алгоритмах (переход на TimSort - хороший пример). В версиях Java 8 впервые был проведен капитальный ремонт системы GC за годы (с устранением PermGen), а улучшения, такие как C4, если они практичны для портирования кросс-платформенных или абстрагированных без существенного отставания от внутренних учетных записей JVM, скорее всего, чтобы быть опробованным, а затем принят в OpenJDK/HotSpot в будущих версиях.

Ответ 3

Реализация сборщиков мусора довольно сложная, и не так много приложений, которые действительно оправдывают бесполезный сборщик. Как вы уже упоминали, барьеры чтения/записи накладывают довольно высокие накладные расходы, которые вы только хотите заплатить, если вам абсолютно нужна низкая латентность и вы готовы поразить пропускную способность.

Тем не менее, в этом JEP реализуется GC с низкой степенью паузы, называемый Шенандоа: http://openjdk.java.net/jeps/189. Будучи программистом на Java, я надеюсь, что он будет доступен через несколько лет.