В Java 11 представлен новый экспериментальный сборщик мусора Epsilon GC. Несмотря на название, он не собирает мусор, а только аллоцирует память и не освобождает её. Соответственно, по исчерпании свободной памяти, возможен креш с OutOfMemory. Для чего такой сборшик мусора может пригодиться?
Зачем?

Согласно JEP318, сборщик мусора Epsilon GC нужен большей частью для тестирования производительности приложения. Например, вы хотите знать, как быстро будет работать ваше приложение, если исключить из тестирования все накладки и задержки, вызванные работой сборщика мусора.
Еще полезно с помощью Epsilon GC оценить сколько вообще мусора способна произвести в heap (memory pressure) ваша программа, если мусор не убирается.
Если ваша программа работает всего одну минуту (Extremely short lived jobs), зачем ей вообще нужен сборщик? Пользуемся Epsilon GC. Тем более, что Java11 теперь поддерживает запуск Java-программы из shell-подобного исходника без всякой предворительной компиляции, как perl-, bash- или python-скрипт.
Но самая изюминка прячется в конце JEP318. Если вы все, что только можно уже соптимизировали и последнее, что мешает вашему приложению быстро работать, это вмешательство сборщика мусора, вы можете перейти на Epsilon GC, с учетом всех рисков (Last-drop latency improvements). Понимаете намёк? Например, если вашей торговой программе выделить всю имеющуюся память под heap, которую она по вашим расчетам в принципе не может за торговый день всю забить мусором, вы можете включить Epsilon GC. Конечно, будет неприятно, если в самый критический момент торгов JVM вылетит с OutOfMemory. Но разве ж это нас останавливало?
Теперь, если мы видим jitter в наших логах, мы не будем кивать на сборщик мусора. Теперь мы понимаем, что все затыки и паузы вызваны нашим кодом (или JIT-компилятором).
Как пощупать это новинку:
java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC
Обратите внимание, что при использовании Epsilon GC, heap уже не делится на Old и Young зоны. Весь heap становится Young зоной и все новые объекты выделяются в ней, пока память не кончится.
ZeroGC
Еще один экспериментальный сборщик мусора, идущий с Java 11, это ZeroGC (JEP333). Это новый сборщик, который готовится в JVM на замену G1 GC. По идее он соптимизирован на работу с heap в сотни гигабайт и даже терабайт. Включается так:
-XX:+UnlockExperimentalVMOptions -XX:+ZeroGC
Shenandoah
Конкурентом ZeroGC выступает еще один экспериментальный сборщик мусора Shenandoah (JEP189). Включается так:
-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC
В заключение
Вообще в Java 11 реализован теперь интерфейс сборщиков мусора (JEP304), который позволяет подключать к JVM сторонние сборщики, как кубики Lego. Вы такой сборщик можете реализвоать сами или получить от стороннего вендора.