Здравствуйте, Ikemefula, Вы писали:

I>>>Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально
I>·>off-heap решения для огромных куч, для старого поколения, а не для молодого. Кстати, с развитием GC необходимость off-heap решений падает.

I> Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении.

Не нужно такого гарантировать, можно вообще ничего не выделять после прогрева и принудительного GC перед началом основной работы. А выделения в G0 сами по себе возникнут, к сожалению.

I>Как только ты перебрал определенный лимит, часть объектов уходит в старое поколение и ты на это никак повлиять не можешь

I>То есть, off-heap нужен для того, что бы исключить gc по максимуму

Не так. Задача — исключить тормозную часть GC, которая на текущих реализациях возникает в основном по старому поколению. Для этого можно убрать новые аллокации вообще, или увести их из managed heap, или заменить алгоритм GC.
Последний вариант был бы самым вкусным, тем более, что инкрементальный GC даже с дефрагментацией это сейчас задача студенческого уровня, но за счёт сильно бо́льших затрат памяти и чистого времени процессора этот вариант невкусен авторам VM. Хотя уже появляются realtime VM такой нацеленности...