runtime: scavenger freezes up in Go 1.14 in Windows due to coarse time granularity [1.14 backport] #38856
Comments
gopherbot
added
the
CherryPickCandidate
|
@mknyszek noted in #38617 (comment) that there is a workaround available:
It's not a great experience, but it is worth considering. /cc @mknyszek @aclements Now that a fix is available, do you have thoughts on how safe it would be to backport this to 1.14? |
|
It's a pretty simple fix. It seems worth back-porting to me. @mknyszek ? |
|
Backporting is fine with me, the change is not very risky. |
|
Change https://golang.org/cl/232743 mentions this issue: |
dmitshur
added
CherryPickApproved
|
Approved per discussion in a release meeting. This is a regression affecting a first class port, the workaround isn't very accessible, and the fix is not high-risk. |
|
Closed by merging b7eca1c to release-branch.go1.14. |
…re defensive This change adds two bits of logic to the scavenger's pacing. Firstly, it checks to make sure we scavenged at least one physical page, if we released a non-zero amount of memory. If we try to release less than one physical page, most systems will release the whole page, which could lead to memory corruption down the road, and this is a signal we're in this situation. Secondly, the scavenger's pacing logic now checks to see if the time a scavenging operation takes is measured to be exactly zero or negative. The exact zero case can happen if time update granularity is too large to effectively capture the time the scavenging operation took, like on Windows where the OS timer frequency is generally 1ms. The negative case should not happen, but we're being defensive (against kernel bugs, bugs in the runtime, etc.). If either of these cases happen, we fall back to Go 1.13 behavior: assume the scavenge operation took around 10µs per physical page. We ignore huge pages in this case because we're in unknown territory, so we choose to be conservative about pacing (huge pages could only increase the rate of scavenging). Currently, the scavenger is broken on Windows because the granularity of time measurement is around 1 ms, which is too coarse to measure how fast we're scavenging, so we often end up with a scavenging time of zero, followed by NaNs and garbage values in the pacing logic, which usually leads to the scavenger sleeping forever. For #38617. Fixes #38856. Change-Id: Iaaa2a4cbb21338e1258d010f7362ed58b7db1af7 Reviewed-on: https://go-review.googlesource.com/c/go/+/229997 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Austin Clements <austin@google.com> (cherry picked from commit c791537) Reviewed-on: https://go-review.googlesource.com/c/go/+/232743
@networkimprov requested issue #38617 to be considered for backport to the next 1.14 minor release.
The text was updated successfully, but these errors were encountered: