Go 1.26: Green Tea GC Новый сборщик мусора (экспериментальный в версии 1.25), в 1.26 будет включен по умолчанию. Мотивация Старый алгоритм сборщика мусора в Go работает с графом: объекты — узлы, а указатели — связи между ними. При этом не учитывается, где именно в памяти находятся эти объекты. Сканер перескакивает между разными участками памяти, из-за чего часто происходят кэш-промахи. В итоге процессор тратит слишком много времени, просто ожидая, когда нужные данные поступят из памяти. Больше 35% времени, потраченного на сканирование памяти, уходит впустую на ожидание доступа к данным. С увеличением числа ядер в процессоре ситуация только ухудшается. Реализация Green Tea меняет подход: теперь в приоритете эффективная работа с памятью. Вместо того, чтобы проверять каждый объект отдельно, система сканирует память блоками по 8 КБ (спанами). Алгоритм работает с маленькими объектами (до 512 байт), потому что их больше всего и их сложнее всего быстро просканировать. Каждый спан делится на одинаковые слоты в зависимости от своего size-класса, и внутри него хранятся только объекты этого класса. Например, если спан относится к классу 32 байта, весь блок делится на слоты по 32 байта, и объекты кладутся прямо в эти слоты (каждый объект в начало отдельного слота). Благодаря такому фиксированному расположению сборщик мусора может легко найти метаданные объекта с помощью простой адресной арифметики, не проверяя размер каждого найденного объекта. Когда алгоритм находит объект, который нужно просканировать, он отмечает его положение в спане, но не сканирует сразу. Вместо этого он ждет, пока в этом же спане не наберется несколько таких объектов. Затем, когда сборщик мусора обрабатывает этот спан, он сканирует сразу несколько объектов. Это намного быстрее, чем проходить по одной и той же области памяти несколько раз. Чтобы лучше утилизировать ядра процессора, GC-воркеры делят работу между собой, «воруя» задачи друг у друга. У каждого воркера есть своя очередь задач, и если воркер простаивает, он может взять задачу из очереди другого, более занятого воркера. Такой децентрализованный подход убирает необходимость в общем списке задач, уменьшает задержки и снижает конкуренцию между ядрами процессора. А еще Green Tea использует векторные инструкции процессора (только на архитектуре amd64), чтобы обрабатывать объекты пачками. Бенчмарки Результаты тестов разнятся, но команда Go ожидает, что в реальных программах, которые сильно зависят от сборщика мусора, затраты на GC снизится на 10–40%. Благодаря векторной реализации, на процессорах вроде Intel Ice Lake или AMD Zen 4 и новее, затраты на GC могут уменьшиться еще на 10%. К сожалению, нормальных актуальных бенчмарков я не нашел 🌚