Алгоритм параллельного уплотнения коллектора

Это просто общее описание алгоритма. Такие описания могут быть разной детализации. В этом случае он дает вам больше информации, но все же оставляет некоторые варианты выбора для разработчика.

По поводу ваших вопросов:

1. So no compaction happened on the "summary phase"? Was the previous phase's purpose only to find all free spaces? - Да, это правильно. На этапе сводки собираются данные индексации и в основном определяется все необходимое, чтобы затем на этапе уплотнения можно было выполнить копирование. Они не говорят, как они реализуют уплотнение, но по умолчанию каждый живой объект просто помещается рядом с предыдущим объектом. По сути, все пустое пространство удаляется, и после завершения этапа уплотнения у вас остается один непрерывный фрагмент памяти, содержащий все живые объекты. Я вижу ваше недоразумение с четвертой частью, но обратите внимание, что она написана в будущем времени: «будет уплотнено» - так что не во время подведения итогов, а позже.
2. Does it mean [...] compacting of this region in not worth the space that could be recovered from such a region? Да, верно. По сути, вы теряете часть места, но очень часто память жертвуется на скорость выполнения. Точный порог плотности зависит от реализации, но я бы оценил пороговое значение отношения используемой памяти к общему объему памяти примерно на уровне 70-90%.

Если вы хотите знать все грязные детали, взгляните на реализации виртуальной машины с открытым исходным кодом, как это предлагается в комментариях.

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

Лучшее решение - использовать профилировщик памяти и уменьшить скорость выделения памяти. Никакая настройка или вмешательство в параметры командной строки (если у вас нет неправильно настроенного сборщика мусора) не сравнится с уменьшением этой скорости распределения.

Однако отвечу на ваши вопросы.

параллельная метка-развертка-компактная

Нет такого такого. Это параллельный сборщик, который сжимает, а параллельный сборщик меток - нет. Существует также коллектор G1, который не является поколением аналогичным образом. т.е. собирает как молодые, так и старые предметы.

Не могу поверить, что эта информация не актуальна для пользователей.

По задумке разработчику не нужно знать такие подробности. Также не стоит чрезмерно настраивать ваше приложение, потому что это делает его очень уязвимым для изменений в приложении или JVM.

Что я хотел бы знать, так это где получить полное описание / информацию о том, как разные сборщики мусора

Вместо того, чтобы говорить, что я хотел бы знать все, что нужно знать (только есть более 500 вариантов), не читая код, вы должны попытаться решить конкретную проблему и задать конкретный вопрос.

Каждый регион будет уплотняться отдельно? Думаю, нет. Так что, может быть, здесь будет какое-то смещение?

Уплотняется только жилое пространство. Молодые регионы копируются многократно и никогда не нуждаются в уплотнении.

Значит, на «итоговой фазе» уплотнения не произошло? Была ли цель предыдущей фазы только найти все свободные места?

На этапе уплотнения выполняется максимальное копирование на один конец области без ее полной дефрагментации. Это оставляет один конец с некоторыми объектами (в основном, большими, как мне кажется), а другой конец очень плотным.