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: shrink stacks more aggressively on explicit GC #8758

randall77 opened this Issue Sep 17, 2014 · 5 comments


None yet
6 participants

randall77 commented Sep 17, 2014

If the user calls runtime.GC or debug.FreeOSMemory, shrink stacks even if they are >
1/4 full.  That way we can reclaim more space (at the expense of incurring runtime cost
when those goroutines start back up).

Maybe also if gp.blockedsince shows the goroutine has been blocked for a long time.

This comment has been minimized.


davecheney commented Sep 17, 2014

Comment 1:

I'm not in favour of this, I think it takes the vague promise that runtime.GC may free
up space on the heap (or not, that's a possibility) and replaces it with a stronger
promise that not only will runtime.GC free heap space, but it will free the maximum
space possible. I think that is not the sort of guarantee runtime.GC should be made to
conform to.

This comment has been minimized.


dvyukov commented Sep 17, 2014

Comment 2:

We are not changing any promises, we just improve quality of implementation.

This comment has been minimized.


davecheney commented Sep 17, 2014

Comment 3:

In my experience, callers of that method from used code do not understand the difference.

This comment has been minimized.


griesemer commented Oct 1, 2014

Comment 4:

Labels changed: added repo-main.

@randall77 randall77 added new labels Oct 1, 2014

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014

@rsc rsc removed the repo-main label Apr 14, 2015


This comment has been minimized.


rsc commented Jun 8, 2015

Not for Go 1.5. Austin and I just found some interactions between the 1/4 and the stack guard; if we'd done this we'd have introduced real bugs.

Maybe for a later release, but I'm skeptical of the benefit here. Mainly it might be useful for triggering stack shrinking bugs.

@rsc rsc modified the milestones: Unplanned, Go1.5 Jun 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment