Компилятор Go использует технику, называемую GCshape stenciling, при компиляции обобщений, представленных в версии 1.18. Исторически сложилось так, что языки реализовывали обобщения либо через полную моноформизацию — генерацию отдельного машинного кода для каждого экземпляра типа, что приводило к увеличению размера бинарников, либо через упаковку — стирание типов за счет накладных расходов во время выполнения и выделения памяти. Проблема, с которой столкнулся Go, заключалась в поддержке высокопроизводительного системного программирования, где важен размер бинарника, без полного жертвования скоростью выполнения.
Решение состоит в группировке конкретных типов по их GC-форме, определяемой их размером и битовой картой указателей (шаблоном указателей внутри типа). Компилятор генерирует единственный экземпляр функции для всех типов, имеющих одинаковую GC-форму, передавая во время выполнения словарь, содержащий метаданные типов, в качестве неявного параметра.
// Оба *int и *string имеют одинаковый экземпляр // потому что они имеют идентичную GC-форму (один указатель). func Identity[T any](x T) T { return x } func main() { Identity((*int)(nil)) // Использует экземпляр #1 Identity((*string)(nil)) // Использует экземпляр #1 (одинаковая форма) Identity(42) // Использует экземпляр #2 (скалярный, без указателей) }
Наша команда строила конвейер обработки событий с высокой пропускной способностью, используя обобщенные обработчики промежуточного программного обеспечения Handler[T Event]. Нам нужно было обрабатывать пятьдесят различных типов событий, при этом поддерживая низкую задержку и разумный размер бинарника для контейнеризованного развертывания.
Первый подход использовал interface{} с утверждениями типов, полагаясь на переключения типов во время выполнения. Это обеспечивало гибкость и работало в более ранних версиях Go, но вводило значительные накладные расходы на выделение памяти — каждое событие, завернутое в интерфейс, требовало выделения памяти в куче — и устраняло безопасность типов на этапе компиляции, приводя к паническим ситуациям в производстве при несовпадении типов.
Второй подход включал генерацию кода на этапе компиляции с использованием go generate и сторонних инструментов для создания HandlerClickEvent, HandlerPurchaseEvent и т.д. Это обеспечивало оптимальную производительность без накладных расходов во время выполнения, но увеличивало размер нашего бинарника на 40 МБ при поддержке пятидесяти типов событий, и создавало кошмары по обслуживанию при обновлении шаблонов генератора.
Мы выбрали третий подход: родные обобщения Go с вниманием к GC-формам. Мы обеспечили, чтобы наши типы событий были указателями на структуры (однородная форма GC), позволяя компилятору повторно использовать экземпляры. Мы согласились на небольшие накладные расходы на поиск в словаре для диспетчеризации методов в обмен на увеличение размера бинарника всего на 2 МБ. Результатом была 15% сокращение задержки по сравнению с interface{} и управляемый размер бинарника по сравнению с полной генерацией кода.
Как словарь во время выполнения предоставляет информацию о типах для общих экземпляров?
Словарь — это структура, содержащая указатели на дескрипторы типов (_type), таблицы методов (itab) и метаданные GC. Когда компилятор генерирует код для обобщенной функции, такой как func Print[T any](x T), он передает словарь в качестве неявного первого аргумента. Чтобы вызвать метод x.String(), сгенерированный код ищет указатель на метод в словаре, а не компилирует прямой вызов, что позволяет одному и тому же машинному коду обрабатывать T=bytes.Buffer и T=strings.Builder, несмотря на разные реализации методов.
Почему два различных типа указателей могут разделять общий экземпляр, в то время как их элементные типы требуют разделения?
Go классифицирует типы по GCshape, что касается только размещения в памяти, относящегося к сборщику мусора и распределителю памяти. И *int, и *string состоят из одного машинного слова, содержащего указатель, что помещает их в один и тот же класс форм. В то же время int не содержит указателей и выравнивается по определенному размеру, в то время как string является двухсловной структурой, содержащей указатель и длину. Поскольку их размещения в памяти различаются, им требуются отдельные сгенерированные кодовые пути для правильного управления сборкой мусора и адресацией в памяти.
Каковы последствия производительности использования методов с получателями значений по сравнению с получателями указателей в обобщенных ограничениях?
Когда обобщенная функция вызывает метод на параметре типа T, компилятор должен генерировать код, который будет работать для любого возможного T. Если ограничение требует получателя значения func (T) Method(), но конкретный тип велик, компилятор может быть вынужден передавать словари и выполнять косвенные вызовы, что предотвращает инлайнинг. Использование получателей указателей func (*T) Method() обычно позволяет лучше оптимизировать, потому что типы указателей чаще разделяют GC-формы, и компилятор может более легко деvirtualize вызовы, когда конкретный тип известен на этапе компиляции в конкретных контекстах экземпляров.