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.

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

runtime: read-only accessor for gcpercent #39419

Open
bsiegert opened this issue Jun 5, 2020 · 3 comments
Open

runtime: read-only accessor for gcpercent #39419

bsiegert opened this issue Jun 5, 2020 · 3 comments

Comments

@bsiegert
Copy link
Contributor

@bsiegert bsiegert commented Jun 5, 2020

I would like to programmatically access the current value of GOGC in my program (for logging it, with various runtime stats).

For GOMAXPROCS, I can call runtime.GOMAXPROCS(0) to get the current value without changing it. However, for GOGC, I see no way of reading the value without writing. I could do a two-step call like

percent := debug.SetGCPercent(100)
debug.SetGCPercent(percent)

but I am worried about the disruption that this may cause in a program that is under load and that has a non-standard GOGC value in the first place.

The documentation for SetGCPercent says that a negative value will disable GC, however there is no documented effect for calling it with 0. Maybe this could be defined to just return the current value, like in GOMAXPROCS? This would just be a matter of making runtime.setGCPercent return early in this case.

@bsiegert bsiegert changed the title Read-only accessor for gcpercent runtime: Read-only accessor for gcpercent Jun 5, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 5, 2020

@dmitshur dmitshur added this to the Backlog milestone Jun 5, 2020
@dmitshur dmitshur changed the title runtime: Read-only accessor for gcpercent runtime: read-only accessor for gcpercent Jun 5, 2020
@mknyszek
Copy link
Contributor

@mknyszek mknyszek commented Jun 6, 2020

Judging by the code, SetGCPercent(0) appears to have the effect of making the trigger ratio 0, so basically a goroutine is going to start a GC whenever it can (except that it has to block until sweeping is done, but it'll help) and the application is basically going to try to continuously stay in the mark phase. I'm not sure if this is useful to anyone, but it is the behavior we currently support (and who knows, maybe someone out there actually uses it; we would break them by changing it). It's sort of documented in that it's in-line with the definition of GOGC: we just simply don't let the heap grow at all before triggering the next GC. I agree this could be made clearer.

As for whether to add a new API call to get the value without modifying it, I'm not opposed. The value can be read by just taking the heap lock. It would've been nice to have it work like GOMAXPROCS for symmetry, but I don't think it's possible at this point without duplicating the API surface. I think to keep things orthogonal if we add something new, whatever we add should just read the value like you suggest and do nothing else.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 7, 2020

Well, if we can't think of anything else:

    n := debug.SetGCPercent(100)
    debug.SetGCPercent(n)
    // Now n is the GOGC value.
    // If you do this at init time it seems unlikely to break anything much.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.