У JRockit есть развитые возможности по тонкой диагностике нагрузки на GC. Правда практически
я это не пробовал. Только смотрел презентации. И запускать нужно не JVisualVM а именно тот
тул который идёт в комплекте с J-Ракетой.

И я-бы думал не о том, сколько Times потребляет GC, а почему GC озадачен
такой нагрузкой и что за объект флудит и почему.

abc_daЗа эти 6 секунд GC собрал порядка 5Гб мусора. Я пытаюсь понять, насколько приемлемо, что CMS-concurrent-sweep занимает столько времени и, если это "плохо", понять, какими параметрами я могу это время сократить. Первое решение по сокращению этого времени, которое приходит - уменьшить размер heap'а. Но, возможно, есть альтернативы?

Для начала сделай дамп хипа в час наибольше нагрузки. И просмотри его через тот-же JVisualVM.
Обрати внимание на count объектов в памяти. У нас часто были DTO/Pojo/Entities которые
database mapper выгребает из БД. Как только узнаешь что за класс объекта флудит - смотри
код. Вполне возможно что SQL запрос выгребает слишком много данных. Дальше решение
лежит в плоскости бизнес задачи.