Память и GC

Рассмотрите ситуацию: сразу после цикла GC отдельные аллокации периодически дают задержки, хотя куча не переполнена. Как отложенная очистка span объясняет это поведение?

В бенчмарке Go много раз создают значения типа struct{}. Почему число таких операций не обязательно означает сопоставимый рост heap и работы GC?

Как выборочное профилирование heap влияет на вывод о числе аллокаций в Go?

Объясните, почему GOMEMLIMIT не гарантирует, что RSS Go-процесса никогда не превысит заданный предел.

От чего зависит, какие слова heap-объекта Go сборщик мусора рассматривает как указатели?

Что позволяет сборщику мусора Go отличать занятые слоты size-класса в span от уже освобождённых?

В каких случаях большой локальный объект Go размещается в куче, даже если он не покидает функцию?

Профиль heap показывает высокий alloc_space, но небольшой inuse_space. Какой вывод о жизненном цикле объектов следует сделать?

Проверьте поведение программы: будет ли вызов runtime.GC() собирать мусор после отключения автоматического GC через debug.SetGCPercent(-1)? Объясните, что именно меняет этот параметр.

package main

import (
    "fmt"
    "runtime"
    "runtime/debug"
)

func main() {
    debug.SetGCPercent(-1)
    data := make([]byte, 1<<20)
    fmt.Println(len(data))
    runtime.GC()
    runtime.KeepAlive(data)
}

Как Go сохраняет корректность указателей на локальные данные при переносе растущего стека горутины?