Воскресный твит Алексея Шипилёва (работающего в Red Hat над OpenJDK) выглядел шуточным, но теперь идея «сборщик мусора, не собирающий мусор» оказалась оформлена уже на полном серьёзе.
В твите говорилось, что отключение GC в HotSpot позволило бы побеждать в любом 5-секундном бенчмарке: с достаточно большой кучей можно продержаться дольше до того, как кончится доступная память.
Учитывая, как часто люди неправильно истолковывают результаты бенчмарков, запись можно было посчитать просто шуткой на эту тему — мол, вот случай, где выигрыш в бенчмарке не будет значить вообще ничего применительно к реальным задачам.
Но затем дело стало стремительно принимать серьёзный оборот: сначала Шипилёв принялся экспериментировать, а теперь и вовсе составил JEP draft с идеей «(не-)сборщика» Epsilon GC, занимающегося только аллокацией памяти и ничего не делающего для её освобождения.
Зачем такое может понадобиться? В драфте перечислены несколько сценариев использования — не то что бы ежедневно нужные каждому разработчику, но всё же реальные.
Один из них — сравнительный анализ: сопоставляя работу Epsilon GC и «обычного» сборщика, можно лучше понять, как обычный влияет на производительность.
Другой — «ультра-чувствительные к производительности приложения», разработчики которых в итоге получают практически не мусорящие решения. По утверждению Шипилёва, в таких экстремальных случаях систематический перезапуск JVM при нехватке памяти может оказываться разумнее, чем сборка мусора. Вспоминается анекдот про нового русского, который покупал новый «Мерседес», когда в старом заполнялась пепельница.
Тем временем сообщество тоже начало искать юзкейсы, и как бы в итоге не оказалось, что был открыт ящик Пандоры:
@saarw That… would… be… horrible.
— Aleksey Shipilëv (@shipilev) February 14, 2017
Алексей ШипилёвРаботает над производительностью Java вот уже почти 10 лет. Успел позаниматься производительностью Apache Harmony в Intel, затем перешёл в Sun Microsystems, а потом и в Oracle, где работал над производительностью Sun/Oracle JDK, в том числе производительностью JVM, библиотек классов, фреймворков и приложений. На данный момент трудится в Red Hat. Являлся техническим представителем Oracle в Standard Performance Evaluation Corporation (SPEC), занятой разработкой и поддержкой промышленных бенчмарков. В данный момент серьёзную часть времени тратит на Java Microbenchmark Harness, инструмент для измерения производительности Java-кода.
