Алексей Шипилёв предложил «GC без GC»

Воскресный твит Алексея Шипилёва (работающего в Red Hat над OpenJDK) выглядел шуточным, но теперь идея «сборщик мусора, не собирающий мусор» оказалась оформлена уже на полном серьёзе.

В твите говорилось, что отключение GC в HotSpot позволило бы побеждать в любом 5-секундном бенчмарке: с достаточно большой кучей можно продержаться дольше до того, как кончится доступная память.

Учитывая, как часто люди неправильно истолковывают результаты бенчмарков, запись можно было посчитать просто шуткой на эту тему — мол, вот случай, где выигрыш в бенчмарке не будет значить вообще ничего применительно к реальным задачам.

Но затем дело стало стремительно принимать серьёзный оборот: сначала Шипилёв принялся экспериментировать, а теперь и вовсе составил JEP draft с идеей «(не-)сборщика» Epsilon GC, занимающегося только аллокацией памяти и ничего не делающего для её освобождения.

Зачем такое может понадобиться? В драфте перечислены несколько сценариев использования — не то что бы ежедневно нужные каждому разработчику, но всё же реальные.

Один из них — сравнительный анализ: сопоставляя работу Epsilon GC и «обычного» сборщика, можно лучше понять, как обычный влияет на производительность.

Другой — «ультра-чувствительные к производительности приложения», разработчики которых в итоге получают практически не мусорящие решения. По утверждению Шипилёва, в таких экстремальных случаях систематический перезапуск JVM при нехватке памяти может оказываться разумнее, чем сборка мусора. Вспоминается анекдот про нового русского, который покупал новый «Мерседес», когда в старом заполнялась пепельница.

Тем временем сообщество тоже начало искать юзкейсы, и как бы в итоге не оказалось, что был открыт ящик Пандоры:

  1. Алексей Шипилёв
    Работает над производительностью Java вот уже почти 10 лет. Успел позаниматься производительностью Apache Harmony в Intel, затем перешёл в Sun Microsystems, а потом и в Oracle, где работал над производительностью Sun/Oracle JDK, в том числе производительностью JVM, библиотек классов, фреймворков и приложений. На данный момент трудится в Red Hat. Являлся техническим представителем Oracle в Standard Performance Evaluation Corporation (SPEC), занятой разработкой и поддержкой промышленных бенчмарков. В данный момент серьезную часть времени тратит на Java Microbenchmark Harness, инструмент для измерения производительности Java-кода. @shipilev
Tags from the story
,