runtime: clarify statement on g object memory lifetime

[minkj1992]

What is the URL of the page with the issue?

https://github.com/golang/go/blob/master/src/runtime/HACKING.md

What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Screenshot

What did you do?

read docs

What did you see happen?

All g, m, and p objects are heap allocated, but are never freed, so their memory remains type stable. As a result, the runtime can avoid write barriers in the depths of the scheduler.

What did you expect to see?

The statement "g objects are heap allocated, but are never freed, so their memory remains type stable" can be misleading. It may imply that the entire memory occupied by a goroutine, including its stack, remains allocated indefinitely.

To address this, proposes the following changes:

Update the documentation:

• Clarify that the statement refers to the g object itself, not the goroutine's stack memory.

• Explain that while the g object is never explicitly freed, its stack memory is eventually reclaimed by the garbage collector.

https://github.com/golang/go/blob/d4112310a4d3b1981d77226a3d52a8b566b0c0bc/src/runtime/proc.go#L4185

[adonovan]

The statement "g objects are heap allocated, but are never freed, so their memory remains type stable" can be misleading. It may imply that the entire memory occupied by a goroutine, including its stack, remains allocated indefinitely.

The statement is explicitly about g objects, not stacks, and the rationale (type stability) dispels any possibility that the sentence is talking about the g's stack (which is constantly changing type).

[prattmic]

cc @golang/runtime

[prattmic]

I think it would be fine to add a paragraph (here or in the "Stacks" section) describing the reuse and freeing of goroutine stacks, as that doesn't seem to be covered elsewhere. Feel free to send a CL.