Когда вы распределяете крупные объекты, которые не вписываются в молодое поколение, они сразу же распределяются в пространстве постоянного поколения. Это пространство доступно только для GC, когда запускается полный GC, который вы пытаетесь форсировать.
Однако я не уверен, что это решит вашу проблему. Вы говорите: «JVM не может выполнить GC достаточно быстро». Даже если ваши распределения происходят пакетами, каждое выделение заставит виртуальную машину проверить, достаточно ли у нее места для этого. Если нет - и если объект слишком велик для молодого поколения - это вызовет полный сборщик мусора, который должен «остановить мир», предотвращая тем самым новые распределения в первую очередь. Как только GC будет завершен, ваш новый объект будет выделен.
Если вскоре после этого в вашем пакете будет запрошено второе большое выделение, оно снова сделает то же самое. В зависимости от того, нужен ли еще исходный объект, он сможет либо успешно выполнить его GC, тем самым освобождая место для следующего выделения, либо потерпеть неудачу, если на первый экземпляр все еще ссылаются.
Вы говорите: «Мне нужен способ [...] быстро освободить достаточное количество памяти (т.е. выполнить полный сборщик мусора), когда заполнение памяти достигает определенного порога»). Это по определению может быть успешным только в том случае, если на это «хорошее количество памяти» больше ничего не ссылается в вашем приложении.
Из того, что я понимаю здесь, у вас может быть состояние гонки, которого вы можете иногда избегать, перемежая запросы GC вручную. В общем, вам никогда не придется беспокоиться об этих вещах - по моему опыту, OutOfMemoryError возникает только в том случае, если на самом деле слишком много выделений для одновременного размещения в куче. Во всех других ситуациях «единственной» проблемой должно быть снижение производительности (которое может стать экстремальным, в зависимости от обстоятельств, но это другая проблема).
Я предлагаю вам сделать дальнейший анализ точной проблемы, чтобы исключить это. Я рекомендую инструмент VisualVM, который поставляется с Java 6. Запустите его и установите плагин VisualGC. Это позволит вам увидеть разные поколения памяти и их размеры. Также есть множество вариантов ведения журнала, связанных с GC, в зависимости от того, какую виртуальную машину вы используете. Некоторые варианты были упомянуты в других ответах.
Другие варианты выбора GC для использования и настройки пороговых значений не должны иметь значения в вашем случае, поскольку все они зависят от наличия достаточного объема памяти для размещения всех объектов, необходимых вашему приложению в любой момент времени. Эти параметры могут быть полезны, если у вас есть проблемы с производительностью, связанные с большой активностью GC, но я боюсь, что они не приведут к решению в вашем конкретном случае.
Как только вы будете более уверены в том, что на самом деле происходит, поиск решения станет легче.