Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: clarify statement on g object memory lifetime #65843

Open
minkj1992 opened this issue Feb 21, 2024 · 3 comments
Open

runtime: clarify statement on g object memory lifetime #65843

minkj1992 opened this issue Feb 21, 2024 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Documentation help wanted NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unreleased

Comments

@minkj1992
Copy link

minkj1992 commented Feb 21, 2024 •
edited

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

Screen Shot 2024-02-21 at 8 54 11 PM

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

func gdestroy(gp *g) {

@gopherbot gopherbot added this to the Unreleased milestone Feb 21, 2024
@seankhliao seankhliao changed the title x/pkgsite: Clarify statement on g object memory lifetime runtime: Clarify statement on g object memory lifetime Feb 21, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 21, 2024
@adonovan
Copy link
Member

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 prattmic added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Feb 21, 2024
@prattmic
Copy link
Member

cc @golang/runtime

@prattmic prattmic changed the title runtime: Clarify statement on g object memory lifetime runtime: clarify statement on g object memory lifetime Feb 21, 2024
@prattmic
Copy link
Member

prattmic commented Feb 21, 2024 •
edited

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
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Documentation help wanted NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Unreleased
Development

No branches or pull requests
6 participants
@prattmic @adonovan @gopherbot @seankhliao @cherrymui @minkj1992