Куча горячей точки (read sun) разделена на несколько частей, поэтому при указании -Xmx вы действительно устанавливаете максимум для всей кучи, а не ее части.
Eden - это небольшая часть общей кучи, она остается небольшой, чтобы приложение не останавливалось в течение длительного периода времени во время сбора. Все новые объекты (которые подходят) входят в eden для начала, если они не являются мусором, они будут продвинуты либо на места выживших, либо на срок пребывания.
Survivor (пространство To / From) - это место, где GC пытается получить объекты, которые могут быть мусором, но не могут быть быстро обработаны во время сбора eden, есть два пространства для выживших, которые действуют как буферы, как один заполнен GC, другой истощен до срока владения, если вы посмотрите на графики, вы увидите, как эти два пространства переворачиваются при использовании.
Срок владения - это место, где находятся долгоживущие объекты, эта куча обычно довольно велика и собирается алгоритмом, отличным от алгоритма eden.
Пермь несколько отделена от остальной части кучи, именно там живут константные строки (любая строка, которая была "интернирована") и байт-код класса. Очень редко нужно настраивать его, обычно его нужно увеличивать только для огромных приложений или для приложений, которые (плохо) автоматически генерируют код.
Без времени паузы я не могу точно сказать, правильно ли настроены ваши настройки JVM, но, судя по вашим размерам кучи, вы используете примерно 1,2 ГБ своего распределения. Если ваше приложение не видит каких-либо неприятных пауз, я думаю, что вы закончили настройку GC (люди часто ездят в город с огромным количеством флагов, не понимая, что они делают, оставляйте флаги, пока вы не докажете себе, что они необходимо)
Вы стремитесь к малой задержке в веб-приложениях, поэтому использование ConcurrentMarkSweep в качестве коллектора владения является разумным выбором.