Можно не дожидаться заполнения кучи и собирать ее при достижении определенного порога
Возьмите виртуальную ЭВМ ( Hyper-V / VMware / VB) уменьшите в параметрах RAM и получите тествый стенд для Garbage Collector
Пока не знаю. Просто попробую это реализовать, и тогда уже смогу точнее сказать.
А нормальный гц делает по-другому? Он срабатывает на пороге, потому что знает, что дальше будет только хуже и пауза будет дольше.
Зачем мне тестовый стенд для гц?
Есть же инкрементальные.
Чтобы с прерываниями поработать. Но это не Вам, это мне надо :)
А что это меняет?
Предсказуемые задержки и мир не останавливают, и место чистят постоянно.
Теплое и мягкое Если он умеет работать в параллель, то это другое. Только параллельные тоже имеют свой STW, потому что мутации все равно никуда не деваются. И мы тут вроде про всякий эмбед, где не уверен что есть параллель. И если он параллельный, то тем более он ориентируется на рантаймовые эвристики, а не на предсказания компилятора. Единственное, что можно сказать на этапе компиляции - "после этой операции можно отдохнуть", но компилятор не в состоянии выдать такое предсказание.
Есть давно устоявшаяся терминология. Parallel GC -- это такой, который собирает мусор в несколько потоков. Мир при этом может стоять на месте. Которые могут работать одновременно с мутатором, называются Concurrent GC.
Зачем в параллель? Компилятор может раскидать по коду вызовы частичной сборки мусора, а там, где нужна аллокация, куча уже будет частично почищена. Да и потом, мы, действительно, говорим об embedded, там не такие большие объёмы данных.
Возвращаемся в самое начало. Компилятор не может сказать сборке мусора "вот тут подождем". Вызывать сборку мусора просто так в надежде на то что это позволит выехать на чистке с непонятной периодичностью при непонятной заполненности абсолютно пустое.
Обсуждают сегодня