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