runtime: objects pointed to by package-level var initializer are not garbage collected after pointer reassignment

[doujianli]

Go version

go version go1.25.5 darwin/arm64

Output of go env in your module/workspace:

n/a

What did you do?

Reproduction

Two functionally identical programs differ only in where the package-level pointer is initialized — inline vs. in init().

leak.go — leaks (inline initialization):

package main

type List struct {
	next *List
}

var l = &List{
	next: &List{},
}

func next() {
	next := l.next
	next.next = &List{}
	l = next
}

noleak.go — no leak (init() initialization):

package main

type List struct {
	next *List
}

var l *List

func init() {
	l = &List{
		next: &List{},
	}
}

func next() {
	next := l.next
	next.next = &List{}
	l = next
}

main.go (test driver):

package main

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

func formatMB(b uint64) string {
	return fmt.Sprintf("%.2f MB", float64(b)/1024/1024)
}

func printMemStats(label string) {
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	fmt.Printf("[%s] HeapAlloc=%s HeapSys=%s HeapObjects=%d NumGC=%d\n",
		label,
		formatMB(m.HeapAlloc),
		formatMB(m.HeapSys),
		m.HeapObjects,
		m.NumGC,
	)
}

func main() {
	printMemStats("init")
	for i := 0; i < 1_000_000; i++ {
		next()
	}
	runtime.GC()
	runtime.GC()
	debug.FreeOSMemory()
	printMemStats("after 1M next")
}

What did you see happen?

Leaking version (inline var initialization):

[init]          HeapAlloc=0.13 MB  HeapSys=3.75 MB   HeapObjects=140      NumGC=0
[after 1M next] HeapAlloc=7.77 MB  HeapSys=11.69 MB  HeapObjects=1000147  NumGC=4

Non-leaking version (init() initialization):

[init]          HeapAlloc=0.13 MB  HeapSys=3.75 MB  HeapObjects=142  NumGC=0
[after 1M next] HeapAlloc=0.14 MB  HeapSys=7.66 MB  HeapObjects=151  NumGC=5

After 1,000,000 next() calls + explicit runtime.GC() + debug.FreeOSMemory():

• Inline initialization: 1,000,147 objects remain on the heap — all 1M discarded nodes are retained, HeapAlloc grows to 7.77 MB.
• init() initialization: only 151 objects remain — old nodes are collected as expected, HeapAlloc stays at 0.14 MB.

Objects created during static package-level initialization appear to bypass normal escape analysis reporting. This suggests the runtime may not register them as regular GC-managed heap objects, causing them to act as pinned roots even after the pointer is reassigned.

What did you expect to see?

Both versions should produce the same heap after GC. Old StorageEvent nodes that are no longer reachable (the global pointer has been reassigned away from them) should be collected.

Each next() call:

1. advances l to its .next
2. allocates a new node as the new tail

The previous head node loses all references and should be eligible for collection.

[gabyhelp]

Related Issues

• runtime: cgocheck fails to correctly identify pinned allocation in self-reference of a linker-allocated object #74116

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

This is likely because of how we do global initializers. We convert some of the allocations to static allocations, whose pointers can then be unfortunately sticky.
We compile to something like:

var l *List = &tmp1
var tmp1 = List{next: &tmp2}
var tmp2 = List{}

You've arranged it just so so that tmp1 keeps the whole list you're building alive.

This has been something I've been thinking about fixing for a long time. It would involve treating global variable slots like we treat stack objects - we would need to separate globals into 2 sections, those directly referenced by code and those that can only be indirectly referenced. We then treat the indirectly referenced ones like heap objects, only scanning them if they are reachable.

It's a pretty big change, though, and doesn't seem particularly high priority.

A workaround is to do l.Next = nil somewhere.

[thepudds]

FWIW, this seems to reproduce with Go 1.17 (a ~randomly selected old version).

AST dump seems to suggest the AS l = PTRLIT{...} being emptied out (perhaps that happens in pkginit, converted to static allocation).

...all of which probably unsurprising based on what Keith just said.

(Just a quick drive-by look by me, so maybe I made a mistake or misunderstood something).

[JunyangShao]

@golang/compiler @golang/runtime