Нуу, тут есть всякие компромиссные пути.

Если экономно мусорить (ну, там всякие строки в куче не выделять, какие-нибудь XML-и держать не в DOM-е, а на линейных буферах с навигационным доступом - т.е. перемещаем Reader по узлам, ну и т.п.), и всякие мелкие объекты использовать повторно через пулы - то можно добиться, что либо вообще почти память не утекает, либо утекает с какой-то известной небольшой скоростью (допустим, N мегабайт в час).

Тогда даже и во многих РВ-системах можно подобрать момент, видимо, когда stop-the-world на определенный краткий период допустим. Ну, вообще есть алгоритмы сборки и без stop-the-world.

Кроме того, если мы не мусорим обломками структур данных (как я описал выше - используем навигационные интерфейсы к структурам данным), то резко уменьшаем количество объектов, подлежащих обходу сборщиком.
Обойти список страниц двоичного буфера, в котором лежит какой-нибудь XML, доступный навигационно - это не то же самое, что обойти его DOM-дерево, где каждый атрибут - это объект...

Не буду говорить за РВ, ибо у меня нет соответствующего серьёзного опыта.
Но в системах массового обслуживания значительно уменьшить нагрузку на менеджер памяти и сборку таким образом можно.