runtime: clarify statement on g object memory lifetime #65843
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
Documentation
Issues describing a change to documentation.
help wanted
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Comments
seankhliao
changed the title
gopherbot
added
the
compiler/runtime
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
added
the
NeedsDecision
|
cc @golang/runtime |
prattmic
changed the title
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
go/src/runtime/proc.go
Line 4185 in d411231
The text was updated successfully, but these errors were encountered: