По какому признаку аллокатор Go выбирает между размерным классом и прямым получением крупного спана из кучи?
Главный признак — размер объекта относительно максимального малого размерного класса, заданного реализацией рантайма. Небольшие объекты размещаются через кэши аллокатора и размерные классы, а крупные получают отдельный спан непосредственно из общей кучи.
Размерные классы появились для ускорения частых малых аллокаций. Вместо обращения к глобальному аллокатору каждый раз рантайм повторно использует заранее подготовленные блоки памяти, снижая конкуренцию между горутинами.
Для крупных объектов такая схема менее эффективна: хранить их в мелких фиксированных классах означало бы увеличивать внутренние потери и усложнять управление большими непрерывными областями. Поэтому для них используется отдельный путь получения спанов.
Если не учитывать различие путей, можно неверно объяснить профиль памяти или задержки. Одинаковое число аллокаций не означает одинаковую стоимость: крупные объекты могут требовать получения новых страниц, их обнуления и последующей работы со страницами кучи.
Нельзя полагаться на конкретное числовое значение границы: размер максимального малого класса является деталью реализации и может изменяться между версиями и архитектурами. Важен сам принцип разделения, а не запоминание порога.
Для малых объектов рантайм округляет запрошенный размер до подходящего размерного класса. Объекты одного класса размещаются в заранее выделенных областях; локальный кэш процессора выполнения позволяет большинству аллокаций обходиться без глобальной блокировки. Когда локальный запас заканчивается, память запрашивается у следующего уровня аллокатора.
Для объекта, превышающего максимальный малый класс, рантайм выбирает крупный спан нужного размера через управление кучей. Такой объект не разбивается на элементы малого класса. После использования спан может быть повторно использован рантаймом, а свободные страницы могут участвовать в работе механизма возврата памяти операционной системе.
Оба пути учитываются сборщиком мусора. Если крупный объект содержит указатели, GC должен сканировать соответствующие области; объект без указателей может быть помечен как неподлежащий сканированию, что уменьшает стоимость маркировки. Сам факт крупного размера не делает объект автоматически дорогим для сканирования — важен layout его типа.
Крупные аллокации могут быть дороже из-за получения новых страниц, обнуления памяти и давления на подсистему управления кучей. Однако маленькие аллокации тоже не бесплатны: при высокой интенсивности они создают поток работы для аллокатора и GC. Поэтому оптимизировать нужно не только количество вызовов, но и размер, время жизни и layout объектов.
В сервисе обработки файлов профили показали редкие аллокации больших временных буферов. Вариант с созданием отдельного большого буфера на каждый запрос был простым, но вызывал скачки потребления памяти и дополнительное обнуление страниц. Полный переход на общий глобальный буфер уменьшал аллокации, но создавал блокировки и риск удержания памяти между запросами.
Выбранным решением стал ограниченный пул буферов с привязкой к размеру задачи и верхним лимитом количества элементов. Пул сократил повторное получение крупных спанов, а лимит не позволил редким большим запросам навсегда удерживать чрезмерный объём памяти. Результат нужно проверять профилями и нагрузочными измерениями: чрезмерное использование пула способно ухудшить локальность и увеличить удерживаемую память.
Всегда ли крупный объект выделяется одним непрерывным участком виртуальной памяти?
Внутри рантайма крупная аллокация получает спан, описывающий непрерывный диапазон страниц виртуальной памяти. Это не означает, что физическая память уже полностью выделена операционной системой: страницы могут подключаться по мере обращения, а часть управления выполняется лениво.
Почему замена одного крупного объекта на множество мелких не обязательно ускоряет программу?
Мелкие объекты лучше используют кэши размерных классов, но увеличивают число объектов, заголовков и потенциальных корней для GC. Если они содержат указатели или живут долго, стоимость маркировки и сопровождения может превысить выигрыш от более удобного пути аллокации.
Должен ли разработчик подбирать размер структуры под размерный класс вручную?
Обычно нет. Искусственное изменение структуры ради попадания в класс может увеличить размер данных, ухудшить читаемость или добавить ненужное выравнивание. Такое решение оправдано только после измерений, когда профили показывают существенные потери на внутреннем фрагментировании или аллокациях; в остальных случаях важнее уменьшить лишние аллокации и удержание объектов.