Все GC, которые я знаю, кроме Azul, несколько параллельны, но имеют хотя бы небольшой компонент stop-the-world. Почему нет большего количества GC, таких как Azul?
Разве Азул запатентовал свою технологию настолько, насколько это невозможно?
Или барьеры для чтения/записи, необходимые для беспроблемной работы, несут слишком много накладных расходов, что они непрактичны для большинства рабочих нагрузок?
Начиная с Java 11, для Linux/x64 JDK доступен новый Z Garbage Collector (ZGC):
Z Garbage Collector, также известный как ZGC, - это масштабируемый сборщик мусора с малой задержкой, разработанный для решения следующих задач:
- Время паузы не превышает 10 мс
- Время паузы не увеличивается с размером кучи или установленного значения
- Обрабатывать кучи размером от нескольких сотен мегабайт до нескольких терабайт
Вы можете включить ZGC, указав следующие аргументы JVM:
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC
Кроме того, начиная с Java 12, имеется Shenandoah GC, доступный для всех платформ. ShenandoahGC имеет те же характеристики, что и ZGC, но его реализация отличается.
Основываясь на документе Azul на C4, похоже, что C4 - это очень новая технология, реализация алгоритма, опубликованного в 2005 году, сначала на специализированном оборудовании, а затем портирована специально для Linux на x86, а реализация JVM находится очень близко к ядру VM.
Поскольку OpenJDK/HotSpot широко используется на нескольких платформах и в крупных производственных нагрузках, он имеет тенденцию двигаться медленнее при принятии крупных инноваций в алгоритмах (переход на TimSort - хороший пример). В версиях Java 8 впервые был проведен капитальный ремонт системы GC за годы (с устранением PermGen), а улучшения, такие как C4, если они практичны для портирования кросс-платформенных или абстрагированных без существенного отставания от внутренних учетных записей JVM, скорее всего, чтобы быть опробованным, а затем принят в OpenJDK/HotSpot в будущих версиях.
Реализация сборщиков мусора довольно сложная, и не так много приложений, которые действительно оправдывают бесполезный сборщик. Как вы уже упоминали, барьеры чтения/записи накладывают довольно высокие накладные расходы, которые вы только хотите заплатить, если вам абсолютно нужна низкая латентность и вы готовы поразить пропускную способность.
Тем не менее, в этом JEP реализуется GC с низкой степенью паузы, называемый Шенандоа: http://openjdk.java.net/jeps/189. Будучи программистом на Java, я надеюсь, что он будет доступен через несколько лет.