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: sweep can be effectively STW #15022

Closed
aclements opened this issue Mar 29, 2016 · 3 comments
Closed

runtime: sweep can be effectively STW #15022

aclements opened this issue Mar 29, 2016 · 3 comments

Comments

@aclements
Copy link
Member

Commit dac220b made pages-in-use accounting continuous, but this accounting has a bug where the count can go negative and wrap around to ~2^64. This causes the sweep ratio computed thereafter to be effectively infinite, so the first allocation on each P in the sweep phase will sweep until the whole heap is swept.

The fix is trivial and should go in to Go 1.6.x. I'll send it out once I can reproduce it in a test.

@aclements aclements self-assigned this Mar 29, 2016
@aclements aclements added this to the Go1.6.1 milestone Mar 29, 2016
@gopherbot
Copy link

CL https://golang.org/cl/21280 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/21456 mentions this issue.

@adg adg modified the milestones: Go1.6.1, Go1.6.2 Apr 7, 2016
@rsc
Copy link
Contributor

rsc commented Apr 7, 2016

OK for 1.6.2

@rsc rsc added the Release-OK label Apr 7, 2016
gopherbot pushed a commit that referenced this issue Apr 14, 2016
When we grow the heap, we create a temporary "in use" span for the
memory acquired from the OS and then free that span to link it into
the heap. Hence, we (1) increase pagesInUse when we make the temporary
span so that (2) freeing the span will correctly decrease it.

However, currently step (1) increases pagesInUse by the number of
pages requested from the heap, while step (2) decreases it by the
number of pages requested from the OS (the size of the temporary
span). These aren't necessarily the same, since we round up the number
of pages we request from the OS, so steps 1 and 2 don't necessarily
cancel out like they're supposed to. Over time, this can add up and
cause pagesInUse to underflow and wrap around to 2^64. The garbage
collector computes the sweep ratio from this, so if this happens, the
sweep ratio becomes effectively infinite, causing the first allocation
on each P in a sweep cycle to sweep the entire heap. This makes
sweeping effectively STW.

Fix this by increasing pagesInUse in step 1 by the number of pages
requested from the OS, so that the two steps correctly cancel out. We
add a test that checks that the running total matches the actual state
of the heap.

Fixes #15022. For 1.6.x.

Change-Id: Iefd9d6abe37d0d447cbdbdf9941662e4f18eeffc
Reviewed-on: https://go-review.googlesource.com/21280
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/21456
Reviewed-by: Andrew Gerrand <adg@golang.org>
@golang golang locked and limited conversation to collaborators Apr 19, 2017
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

4 participants