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

Open
randall77 opened this Issue Sep 17, 2014 · 5 comments

Comments

Projects
None yet
6 participants
@randall77
Contributor

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.
@davecheney

This comment has been minimized.

Contributor

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.
@dvyukov

This comment has been minimized.

Member

dvyukov commented Sep 17, 2014

Comment 2:

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

This comment has been minimized.

Contributor

davecheney commented Sep 17, 2014

Comment 3:

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

This comment has been minimized.

Contributor

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

@rsc

This comment has been minimized.

Contributor

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