Skip to content

runtime: consider rescanning stacks before mark termination #12061

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

Closed
aclements opened this issue Aug 6, 2015 · 1 comment
Closed

runtime: consider rescanning stacks before mark termination #12061

aclements opened this issue Aug 6, 2015 · 1 comment

Comments

@aclements
Copy link
Member

Mark termination does not have to rescan stacks that haven’t executed since the last scan and it doesn’t have to rescan above the lowest stack barrier. But a lot can happen between concurrent scan and mark termination that leaves mark termination with a lot of stack scanning work. We should think about how we can reduce this.

One way is to rescan stacks toward the end of the concurrent mark phase (perhaps as part of entering mark 2) to close the gap during which stacks can become dirty.

Another possibility (suggested by @RLH) is to rescan stacks on preemption. A potential downside of this is that a goroutine can be preempted many times during concurrent mark, and ultimately only the most recent scan matters. It may also cause us to retain more floating garbage.

@aclements aclements added this to the Go1.6Early milestone Aug 6, 2015
@rsc
Copy link
Contributor

rsc commented Nov 4, 2015

Considered but not done. Maybe later, maybe not.

@rsc rsc closed this as completed Nov 4, 2015
@golang golang locked and limited conversation to collaborators Nov 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants