Как фазы меток и разверток .NET GC могут работать одновременно с потоками приложений?

Question

как фазы меток и разверток .NET GC могут работать одновременно с потоками приложений?

Answer 1

Я не уверен, что это так.По словам Маони Стивенса блог .

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

Она не прописывает эти фазы.

Также из записи

Параллельный сборщик мусора, с другой стороны, работает одновременно с управляемыми потоками в следующем расширении:

§ Он позволяет выделятьв то время как одновременный сборщик мусора выполняется.

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

§ Во время одновременной сборки мусора все равно необходимо несколько раз останавливать управляемые потоки.

Во время параллельного GC нам нужно дважды приостановить управляемые потоки, чтобы выполнить некоторые этапы GC.Эти фазы могут занять некоторое время, чтобы закончить.Мы делаем параллельные GC только для полных GC.Полный GC может быть либо одновременным GC, либо блокирующим GC.Эфемерные GC (то есть gen0 или gen1 GC) всегда блокируют.Concurrent GC доступен только для рабочей станции GC.В GC на сервере мы всегда блокируем GC для любых GC.

Вас также может заинтересовать это видео .

Answer 2

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

Как указано в блоге, одновременная коллекция происходит только во время коллекции второго поколения, которая может кусаться, потому что нет разумного верхнего предела числаобъектов, которые могут быть в этом поколении.И может заметно повлиять на отзывчивость приложения с графическим интерфейсом на рабочей станции.Gen # 0 и # 1 уже собраны, оставляя приличный кусок памяти для выделения.Он может запустить граф объектов №2, которые он обнаружил при сборе 0 и 1.

Я думаю, что GC сначала приостанавливает все потоки, чтобы он мог безопасно обходить их стек и регистры ЦП, чтобы найти ссылки на объекты.Это может произойти довольно быстро.И добавляет их к графику.

Теперь он может освобождать потоки, они могут продолжать работать, не опасаясь, что ссылки на объекты станут недействительными, потому что еще ничего не перемещается.Распределение от поколения # 0 не проблема, возможно это может даже собрать # 0, если это заполняется.В сообщении блога говорится, что это так.

Тем временем, сборщик может пройти поколение №2 и добавить ссылки на график из объектов, находящихся там.И узнайте, на какие объекты больше нет ссылок.Потоки работают, пока это происходит.Если нижние поколения не заполнятся, то поток, который выделяет, запускается в блокировку.

Затем ему нужно снова приостановить потоки, чтобы он мог уплотнить поколение # 2, перемещая объекты и обновляя их ссылки.Количество времени, которое может занять довольно непредсказуемо.Я не понимаю, будет ли он перемещать гигабайт объектов, чтобы заполнить дыру в 16 байт, которая стала свободной в начале кучи.Я серьезно сомневаюсь, что это занимает всего 200 мсек.

Одним из следствий этой теории является то, что она не будет выпускать объекты поколения № 2, на которые не ссылались во время работы потоков во время сбора.Это может быть способ проверить эту теорию, хотя я не вижу хорошего способа сделать это.