VladD2 wrote:
> C>Как будто .NETвый GC сильно лучше.
> Секундных задержек точно не замечано.
Вполне заметно для некоторых сценариев использования.

Тут все зависит от вида графа объектов и их разделению между потоками.
Если каждый поток будет работать в основном со своими данными, то пауз
почти не будет — так как мусоросборщику не надо будет останавливать все
потоки (.NETовый и JVMные сборщики используют механизм защиты памяти для
остановки потока, если он обращается к данным, с которыми сейчас
работает GC). Точно так же, если данные будут не очень сильно связные,
то упаковщик пройдет по ним достаточно быстро и паузу можно не заметить.

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

Я мониторил GC — сначала он достаточно долгое время использует полностью
конкуррентный mark&sweep (для старшей кучи, молодое поколение не
рассматриваем), но постепенно куча фрагментируется и он запускает
упаковщик. А это как раз и дает паузу.

А упаковка нескольких гигабайт объектов (даже параллельно на двух
процессорах) — занятие не мгновенное, как ни бейся.

Консультанты из Tangosol говорят, что их систему используют несколько
банков как раз для того, чтобы избежать этих пауз в GC с помощью их
системы распределенных запросов.