Периодически попадаются статьи, в которых пишут что-то вроде "у нас stop-at-word gc повесил систему на пять минут" (hotspot server vm). Я вот сколько раз пытался написать прогу, которая специально создаст "тяжелые" для gc условия - не выходило.

вопрос вот в чем - с 512мб хипа по умолчанию это вообще реально? Ну, пускай не на 5 минут подвесить, но секунд хотя б на 10. Или нужны сотни гигабайт?

То есть задача состоит в том, чтобы сделать что-либо, чтобы одно new вызвало stop-at-word и секунд хотя бы 10 все висело.

Вобщем, как оказалось, нагрузить gc таким способом довольно легко, причем хватает даже пункта 1, но вот механизм загрузки получился несколько не тот, который я хотел получить.

Ранее я делал так - запоняется большой массив обьектов до большого размера, потом в нем четные объекты удаляются. Потом он снова заполняется и тд. Этот тест у меня не грузил gc и не сохранился.

Если же создавать делать много связанных обьектов, то full gc вызывается уже на этапе их создания, причем бывает что по нескольку раз. Это в сборке 1.7.0_21. Я так понимаю, что ей перестает хватать eden, поэтому обьекты форсированно уходят в survivol/tenured, но предварительно вызывается fullgc. И он пробегает по всем связям, что занимает время. То есть, даже создать много обьектов - это уже проблема.

проект я закинул на https://github.com/chabapok/gc-perfkiller.git
там до п2. дело не доходит и код не дописан, взможно чуть позже попробую что будет.

Если запускать его с -Xmx512m то тормозов много. Full gc бывало что вызывался по 3 раза подряд, и между вызовами поток с максимальным приоритетом не просыпался, таким образом у меня получалось diff=14сек тормозов.
Если дать ей -Xmx4G, то full gc все равно вызывается но значительно реже, тормоз максимальный 2.8сек получался.

Таким образом я сделал следующие выводы.
Тормоза gc может вызывать в том числе (но не ограничиваясь) и от того, что ему мало памяти. Это очень интересный момент, потому что раньше я думал, что чем меньше памяти, тем быстрей gc может ее оббежать - то есть будет вызываться чаще но stop the world будет занимать меньшее время. Оказывается, нет.

Хотелось воспроизвести именно тормоза на чистке большого количества долголежащих обьектов, ставших ненужными. Получилось сделать, насколько я понимаю, тормоза на их создании. При этом, хотя на этапе создания я не делал временных обьектов, gc все равно что-то находил и подчищал.

Насколько тест был корректным - не знаю.

А я вас не игнорирую, я вам не верю :))

gc должен сканировать и то и другое, потому что, чтобы не сканировать мертвые обьекты, нужно сначала понять, что их сканировать не надо. gc должен вычислять "дырки" и при надобности переносить обьекты или ремапить память (но ведь это прерогативая ядра?), чтобы освобождать непрерывные регионы, (если это требуется). Собственно, я думал (по всей видимости - неверно), что основаня работа - копирование участков памяти.

Другое дело, что живые сканировать так или иначе придется постоянно, а уже недоступные - только однажды/несколько раз.

Ну это больше вопрос терминологии, мне кажется.
Что такое "сканирует"? Обойти и маркировать - да, только живые. Как же иначе.

Но попробуйте сделать свой аллокатор c функцией освобождения реализованной через mark&sweep - вы очень быстро поймете, что маркировка - это лишь одна из фаз. Когда вам нужно найти память для очередного new - надо искать "дырки" в памяти. То есть так или иначе, в неявной форме опрерировать пространством адресов, в которых раньше могло что-то храниться. Можно ли это назвать сканированием? Можно ли назвать обходом неживых обьектов? Не важно как мы это назовем. Все равно мы оперируем этими сущностями.

забыл ник,

А, ну это да. Я просто не сразу врубился о чем вы. С процессом маркировки - ясно.

теперь про другое.

Full GC когда вызывается? когда не хватает памяти для аллоцирования. И что происходит -- надо просканить все связи и дефрагментировать память. Это я правильно понял?
Была прога когда связей мало, а дефрагментировать надо много. И был прога когда связей много, но недоступных обьектов мало.

Вторая прога явно нагружает проц сильней, при равном кол-ве объектов. Мне это показалось странным.