Память и GC

Какие последствия для кучи имеет неперемещающий сборщик мусора Go?

В сервисе после удаления большинства записей из большой map объём памяти процесса почти не изменился. Какой механизм Go объясняет это поведение?

Что происходит с недостижимым объектом до следующего запуска сборщика мусора?

Верно ли, что сборка мусора в Go полностью останавливает выполнение пользовательских горутин?

В контейнере Go-процесс приближается к мягкому лимиту памяти, хотя GOGC не меняли. Как это влияет на частоту сборки мусора?

В высоконагруженном Go-сервисе аллокации малых объектов не стали пропорционально медленнее после роста числа горутин. Как устройство аллокатора объясняет такую масштабируемость?

На профиле CPU видно, что создание больших временных объектов заметно расходует процессор, хотя сборщик мусора почти не находит их живыми. Какой этап аллокации объясняет этот эффект?

Объясните механизм: когда ссылка на объект в локальной переменной перестаёт удерживать его от сборки мусора до выхода из функции?

При редких, но заметных STW-паузах Go-сервиса что главным образом определяет длительность финальной фазы маркировки?

Откуда берётся стоимость обнуления памяти при аллокации в Go?

Представьте сервис с десятками тысяч горутин: стек каждой вырос, но объём heap почти прежний. Что именно в работе GC может увеличить затраты на маркировку?

После глубокой рекурсии память, занятая стеками горутин, долго не уменьшается. Каким механизмом Go решает, когда уменьшать выросший стек?

Предскажите, почему отключение инлайнинга способно изменить решение escape analysis для временного результата.

В Go-сервисе после добавления большого глобального массива указателей время каждого цикла GC выросло, хотя число живых объектов почти не изменилось. Какой механизм объясняет этот рост?

По какому признаку аллокатор Go выбирает между размерным классом и прямым получением крупного спана из кучи?

За счёт чего сборщик мусора Go не принимает каждое машинное слово в стеке за указатель?

Разработчик сохраняет адрес объекта в uintptr, не оставляя typed pointer. Может ли сборщик мусора считать объект живым до обратного преобразования?

В Go map резко выросла, и потребление памяти временно приблизилось к двойному, хотя записи не дублировались логически. Каким механизмом роста хеш-таблицы объясняется этот пик?

В структуре переставили поля, не изменив их типы. При каких условиях это уменьшит расход памяти программы?

Почему указатель на один элемент большого массива может удерживать от сборки мусора весь объект?