Сборщик Мусора Go: Решение Проблемы Отзывчивости В Go 1.5

Этот материал представляет собой перевод поста в блоге, написанного в реальном времени ребятами из Sourcegraph с конференции GopherCon 2015, которая проходит в эти дни в Денвере, штат Колорадо.

Полное видео и слайды презентации будут добавлены в публикацию, как только они станут доступны.

Ричард Л.

Хадсон (Рик) известен своими работами в области управления памятью, включая изобретение алгоритмов Train, Sapphire и Mississippi Delta, а также карт стека GC, которые позволили собирать мусор в статически типизированных языках, таких как Java, С# и Го.

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

Рик в настоящее время является частью команды Go в Google, работая над сборкой мусора и проблемами времени выполнения.



Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

В экономике существует понятие «замкнутого цикла», когда один процесс усиливает другой, что приводит к усилению первого.

Исторически в мире компьютеров существовал такой «замкнутый цикл» между развитием аппаратного и программного обеспечения.

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

Этот цикл работал примерно до 2004 года, когда закон Мура перестал работать.



Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Сегодня удвоение количества транзисторов не означает удвоение скорости программ.

Больше транзисторов == больше ядер ЦП, но программное обеспечение еще не достаточно развито, чтобы использовать больше ядер.

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

Цикл застопорился.

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

Более краткосрочная задача — повысить популярность Go мировым сообществом разработчиков.

И одна из самых больших претензий к Go на данный момент заключается в том, что сборщик мусора делает слишком длительную паузу.

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

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

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Но Расс Кокс по каким-то причинам отверг эти идеи, и они решили засучить рукава и действительно улучшить сборщик мусора в Go. Они придумали алгоритм, который уменьшает паузы GC, но делает программу немного медленнее.

Программы Go станут немного медленнее в обмен на гарантированную низкую задержку на этапах сборки мусора.

Какие задержки мы можем выделить? Наносекунда: Грейс Хоппер сравнила время с расстоянием.

Наносекунда равна 11,8 дюймам.

Микросекунда: 5,4 микросекунды — это время, за которое свет проходит 1 милю в вакууме.

Миллисекунды: 1: Последовательное чтение 1 МБ с SSD. 20: Чтение 1 МБ с вращающегося диска.

50: Порог восприятия (порог реакции) 50+: Различные задержки в сети 300: Моргание глаз Так какой же объем работы по сбору мусора мы можем выполнить за одну миллисекунду?

Java GC против Go GC



Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Идти:
тысячи горутин синхронизация по каналам среда выполнения написана на Go с использованием его функций, как и обычный код. контроль пространственной локальности (можно встраивать структуры, внутренние указатели (&foo.field)) Джава: десятки потоков Java синхронизация через объекты/замки среда выполнения написана на C объекты связаны через указатели Самым большим отличием здесь является проблема пространственной локализации.

В Java все является указателем, но в Go можно встраивать структуры друг в друга.

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



Основы сборщика мусора

Вот краткий пример того, как работает сборщик мусора.

Обычно он состоит из двух этапов:

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Фаза сканирования: определите, какие объекты в куче доступны.

Сюда входят указатели на стеки, регистры, глобальные переменные, а затем указатели на кучу.

Фаза маркировки: перемещение по графику указателя.

Отмечайте объекты как доступные во время выполнения программы.

С точки зрения сборщика мусора, проще всего «остановить мир», чтобы указатели вообще не менялись на этом этапе.

По-настоящему параллельный сборщик мусора очень сложно реализовать, поскольку указатели постоянно меняются.

Программа использует так называемые «барьеры записи», чтобы сообщить сборщику мусора, что этот объект не следует захватывать.

Однако на практике барьеры в регистрации могут привести к результатам даже хуже, чем «остановка мира».



Сборщик мусора в Go

Новый алгоритм сборки мусора Go использует комбинацию барьеров записи и коротких пауз, чтобы «остановить мир».

Вот его фазы:

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Вот как выглядел сборщик мусора в Go 1.4:

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

А вот как это выглядит в Go 1.5:

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Обратите внимание, что паузы для «остановки мира» намного короче.

Когда работает параллельный сборщик мусора, он использует 25% процессора.

Вот результаты испытаний:

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

В предыдущих версиях Go паузы сборщика мусора обычно были намного дольше и увеличивались по мере увеличения размера кучи.

В Go 1.5 паузы сборщика мусора стали более чем на порядок короче.

Если вы увеличите цифры, вы увидите, что все еще существует слабая положительная корреляция между размером кучи и длиной пауз GC. Но они знают, в чем проблема, и она будет исправлена в Go 1.6.

Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

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



Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5



Взгляд в будущее

Сообщите людям, что паузы GC больше не являются проблемой в Go. Заглядывая в будущее, они планируют настроить сборщик мусора, чтобы сделать паузы еще короче, повысить производительность и повысить предсказуемость.

В этом компромиссе они хотят найти оптимальный баланс.

Развитие Go 1.6 будет зависеть от отзывов, поэтому они очень ждут отзывов сообщества.



Сборщик мусора Go: решение проблемы отзывчивости в Go 1.5

Новый сборщик мусора сделает Go еще более подходящей заменой языков с ручным управлением памятью.



Ссылки

Слайды: talks.golang.org/2015/go-gc.pdf

Подробнее о сборщике мусора в Go

Скорость одновременного сбора мусора Go 1.5 План и дорожная карта Go 1.4+ по сбору мусора (GC) Теги: #Go #сборщик мусора #сборка мусора #задержка #Высокая производительность #программирование #Системное программирование #Go
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.