2013-12-06 3 views
3

У меня есть два вопроса. И один из них будет оскорблять тему :)Алгоритм параллельного компактирования коллектора

1) Я столкнулся с проблемой неспособности найти полную информацию о том, как работает сборщик мусора в HotSpot. Но я не говорю об общих описаниях работы сборщика мусора (у нас есть много этой информации в Интернете), я говорю о конкретных алгоритмах. Я нашел этот документ (управление памятью в виртуальной машине Java HotSpot) http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf. Но у него есть только общие идеи. У этого есть хорошее описание (вероятно, это не так хорошо - см. Мой второй вопрос) алгоритма параллельного уплотнения (я имею в виду параллельный метка-развертка-компакт), но он не объясняет другие алгоритмы сборщика мусора. Однако этот документ - лучшая информация, которую я смог найти в Интернете. Я хотел бы знать, где получить полное описание/информацию о том, как разные сборщики мусора (для молодого поколения я имею в виду: ParNew, DefNew, PSYoungGen, для старого поколения: PSOLdGen, ParOldGen, Concurrent-Mark-Sweep). Не могу поверить, что эта информация недоступна для пользователей.

2) Вопрос о алгоритме параллельного компакционного коллектора (ParOldGen или Parallel Mark-Sweep-Compact). В техническом документе (см. Первый вопрос) есть описание его работы. Позволь мне вставить цитату из официального документа (пожалуйста, потратьте минуту, чтобы посмотреть на него): enter image description here

Вещь, которые я не могу понять, перечислены ниже:

Что касается суммарной фазы:

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

хорошо, это значит, что, когда у нас есть область, которые состоят из 98-99% живых объектов и 2-1% мертвых объектов (другими словами, очень небольшой процент мертвых объектов), чем уплотнение этой области не стоит пространства, которое можно было бы восстановить из такой области. Однако эти маленькие свободные пространства (отверстия) будут в конечном итоге заполнены, и после сбора мусора не будет отверстий.

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

хорошо, если у нас есть большой процент мертвых объектов, чем этот регион стоит уплотнения, не так ли?

  • Области слева от этой точки, называются плотной префикса, и никакие объекты не перемещаются в этих регионах.

«и никакие объекты не перемещаются в этих регионах», но там могут быть некоторые небольшие свободные пространства в тех регионах, я прав? Не могу uderstand точки

  • регионов справа от этой точки будет уплотнен, устраняя все мертвое пространство.

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

  • Фазовые вычисляет и сохраняет суммарные новое местоположение первого байта данных в реальном времени для каждого уплотненного региона.

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

В отношении фазы уплотнения:

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

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

Пожалуйста, помогите мне получить четкое изображение.

+2

Я не знаю, как они работают, и я не делал этого сам, но для вас может быть полезно прочитать код сборщика мусора в OpenJDK. – tmyklebu

+1

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

+1

«Однако эти крошечные свободные пространства (отверстия) в конечном итоге будут заполнены, и после сбора мусора не будет никаких отверстий». Не так, как я это понимаю. Точка не является обычной кучей. «Отверстия» не заполняются. Вместо этого вы ожидаете, пока вся область не будет уплотнена. «Compacting» для большинства областей Hotspot подразумевает копирование всех объектов из старого пространства в новое пространство, пропуская «дыры». Точка доступа, по большей части, является сборщиком «стоп и копия». –

ответ

3

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

Что касается ваших вопросов:

  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%.

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

1

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

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

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

параллельно знак развертки компактный

Там нет такого это. Это параллельный коллектор, который сжимается и Concurrent Mark Sweep, который этого не делает. Существует также сборщик G1, который не является поколением таким же образом. т. е. собирает как молодые, так и старые объекты.

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

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

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

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

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

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

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

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

+0

« Будьте дизайнером, разработчику не нужно знать эту деталь ». Только в модели, где разработчики должны заботиться только о формальной семантике своих программ Java, а не о тех реальных эффектах (времени и пространства), которые не воспринимаются формальной семантикой. – tmyklebu

+0

@tmyklebu В действительности, они должны иметь некоторую идею, но если вам нужно точно знать, как работает уплотнение, вы сделали что-то неправильное ИМХО. Обычно добавление еще нескольких ГБ в кучу решает эту проблему, намного дешевле в долгосрочной перспективе (1 ГБ стоит 3 доллара США) и занимает гораздо меньше времени. –

+2

Зная, как что-то работает, вы можете создать свои сильные стороны. «Просто купить больше ОЗУ» - это не всегда вариант; современные материнские платы имеют очень ограниченную способность принимать палочки ОЗУ и использовать их. Расширение кучи может привести к тому, что паузы GC занимают больше времени, что отрицательно сказывается на латентности. (Хотя я бы согласился с тем, что вы находитесь в глубоком состоянии греха, если эта деталь сделает или сломает ваш проект, и вы не уйдете от среды GC'd.) – tmyklebu

Смежные вопросы