Какой сборщик мусора использует Go? - PullRequest
101 голосов
/ 19 октября 2011

Go - это язык для сборки мусора:

http://golang.org/doc/go_faq.html#garbage_collection

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

Это все еще разметка?Это консервативный или точный?Это поколение?

Ответы [ 5 ]

108 голосов
/ 19 октября 2011

Планы на сборщик мусора Go 1.4+:

  • гибридный стоп-мир / параллельный коллектор
  • часть "остановка мира" ограничена 10-месячным сроком
  • Ядра процессора, предназначенные для одновременной работы коллектора
  • алгоритм трехцветной маркировки и развертки
  • не поколения
  • без уплотнения
  • полностью точный
  • понесет небольшую стоимость, если программа перемещает указатели вокруг
  • меньшая задержка, но, скорее всего, также меньшая пропускная способность, чем у Go 1.3 GC

Обновления Go 1.3 для сборщика мусора поверх Go 1.1:

  • одновременная развертка (приводит к меньшему времени паузы)
  • полностью точный

Go 1.1 сборщик мусора:

  • mark-and-sweep (параллельная реализация)
  • не поколения
  • без уплотнения
  • в основном точные (кроме стековых фреймов)
  • стоп-мир
  • растровое представление
  • нулевая стоимость, когда программа не выделяет память (то есть: перемещение указателей происходит так же быстро, как в C, хотя на практике это работает несколько медленнее, чем в C, поскольку компилятор Go не так продвинут, как компиляторы C, такие как GCC )
  • поддерживает финализаторы на объектах
  • нет поддержки слабых ссылок

Go 1.0 сборщик мусора:

  • То же, что и Go 1.1, но вместо того, чтобы быть в основном точным, сборщик мусора является консервативным. Консервативный GC может игнорировать объекты, такие как [] byte.

Замена ГХ на другую противоречива, например:

  • за исключением очень больших куч, неясно, будет ли GC поколения быстрее в целом
  • «небезопасно» затрудняет реализацию полностью точного ГХ и сжатие ГК
30 голосов
/ 17 марта 2015

(Для Перейти 1.8 - 1 квартал 2017 года, см. Ниже )

Следующий переход 1.5 одновременный Сборщик мусора предполагает возможность «шагать» по указанному gc.
Вот предложение, представленное в этой статье , которое может сделать его для Go 1.5, но также помогает понять gc в Go.

Вы можете увидеть состояние до 1.5 (Stop The World: STW)

До Go 1.5 Go использовал параллельный коллектор Stop-the-World (STW).
Во время сбора STWимеет много минусов, по крайней мере, имеет предсказуемое и контролируемое поведение роста кучи.

https://40.media.tumblr.com/49e6556b94d75de1050c62539680fcf9/tumblr_inline_nr6qq8D9FE1sdck2n_540.jpg

(Фото с GopherCon 2015 презентация " Go GC: решение проблемы задержки в Go 1.5 ")

Единственной ручкой настройки для коллектора STW был« GOGC », относительный рост кучи между коллекциями.Значение по умолчанию, 100%, запускает сборку мусора каждый раз, когда размер кучи удваивается по сравнению с размером динамической кучи по сравнению с предыдущей коллекцией:

https://docs.google.com/drawings/image?id=sLJ_JvGfPfPnojLlEGLCWkw&rev=1&h=113&w=424&ac=1

Время GC в STWсборщик.

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

https://40.media.tumblr.com/783c6e557b427a5c023520578740eb94/tumblr_inline_nr6qqpmaJx1sdck2n_540.jpg

(Фото с GopherCon 2015 презентация " Go GC: решение проблемы задержки в Go 1.5 ")

Для достижения того же предела роста кучи среда выполнения должна начинать сборку мусора раньше, но насколько раньше это зависит от многих переменных, многие из которых не могут быть предсказаны,

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

Достижение правильного баланса без ущерба для параллелизма требует тщательной стимуляции сборщика мусора.

Шаг GC направлен на оптимизацию по двум измерениям: увеличение кучи и загрузка ЦП сборщиком мусора.

https://docs.google.com/drawings/image?id=sEZYCf7Mc0E0EGmy4gho3_w&rev=1&h=235&w=457&ac=1

Конструкция GC-кардиостимуляции состоит из четырех компонентов:

  1. оценщик для объема сканирования работы цикла GCпотребуется
  2. механизм для мутаторов, чтобы выполнить расчетный объем работы сканирования к тому времени, когда выделение кучи достигнет цели кучи,
  3. планировщик для фонового сканирования, когда помощь мутатора приводит к недостаточному использованию бюджета ЦП,и
  4. пропорциональный контроллер для триггера ГХ.

В проекте сбалансировано два разных представления времени: время ЦП и время кучи .

  • Процессорное время похоже на стандартное время настенных часов, но проходит в GOMAXPROCS раз быстрее.
    То есть, если GOMAXPROCS равно 8, то проходит восемь секунд процессоракаждую секунду, и GC получает две секунды времени ЦП каждую секунду.
    Планировщик ЦП управляет временем ЦП.
  • Прохождение времени кучи измеряется в байтах и ​​движется вперед по мере выделения мутаторами.

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

18 голосов
/ 19 октября 2011

Это реализация GC: * ​​1001 *

https://github.com/golang/go/blob/master/src/runtime/mgc.go

Из документов в источнике:

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

8 голосов
/ 29 октября 2016

Go 1.8 GC может развиваться снова, с предложением «Устранить повторное сканирование стека STW»

Начиная с Go 1.7, единственным оставшимся источником неограниченного и потенциально нетривиального stop-the-world (STW) времени является повторное сканирование стека.

Мы предлагаем исключить необходимость повторного сканирования стека, переключившись на гибридный барьер записи, который сочетает в себе барьер удаления записи в стиле Yuasa [Yuasa '90] и вставку в стиле Дейкстры. барьер записи [Дейкстра '78] .

Предварительные эксперименты показывают, что это может сократить время STW в худшем случае до менее 50 мкс , и этот подход может сделать практичным полное устранение прекращения метки STW.

Здесь объявлено , и вы можете увидеть соответствующий исходный коммит d70b0fe и ранее.

2 голосов
/ 20 октября 2011

Я не уверен, но я думаю, что текущий (совет) GC уже параллельный или, по крайней мере, это WIP. Таким образом, свойство «стоп-мир» больше не применяется или не будет применяться в ближайшем будущем. Возможно, кто-то другой сможет разъяснить это более подробно.

...