runtime: TestGcSys fails on Windows #27156
Labels
Milestone
Comments
bradfitz
added
OS-Windows
NeedsFix
|
Change https://golang.org/cl/130875 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 22, 2018
This is causing failures on TryBots and BuildBots:
--- FAIL: TestGcSys (0.06s)
gc_test.go:27: expected "OK\n", but got "using too much memory: 39882752 bytes\n"
FAIL
Updates #27156
Change-Id: I418bbec89002574cd583c97422e433f042c07492
Reviewed-on: https://go-review.googlesource.com/130875
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/184097 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 4, 2019
This change makes it so that if we're already finding ourselves in a situation where we've done more scan work than expected in the steady-state (that is, 50% of heap_scan for GOGC=100), then we fall back on the hard heap goal instead of continuing to assume the expected case. In some cases its possible that we're already doing more scan work than expected, and if GC assists come in just at that window where we notice it, they might accumulate way too much assist credit, causing undue heap growths if GOMAXPROCS=1 (since the fractional background worker isn't guaranteed to fire). This case seems awfully specific, and that's because it's exactly the case for TestGcSys, which has been flaky for some time as a result. Fixes #28574, #27636, and #27156. Change-Id: I771f42bed34739dbb1b84ad82cfe247f70836031 Reviewed-on: https://go-review.googlesource.com/c/go/+/184097 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
|
This should be fixed now as of aae0b5b. |
t4n6a1ka
pushed a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
This change makes it so that if we're already finding ourselves in a situation where we've done more scan work than expected in the steady-state (that is, 50% of heap_scan for GOGC=100), then we fall back on the hard heap goal instead of continuing to assume the expected case. In some cases its possible that we're already doing more scan work than expected, and if GC assists come in just at that window where we notice it, they might accumulate way too much assist credit, causing undue heap growths if GOMAXPROCS=1 (since the fractional background worker isn't guaranteed to fire). This case seems awfully specific, and that's because it's exactly the case for TestGcSys, which has been flaky for some time as a result. Fixes golang#28574, golang#27636, and golang#27156. Change-Id: I771f42bed34739dbb1b84ad82cfe247f70836031 Reviewed-on: https://go-review.googlesource.com/c/go/+/184097 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Exposed by https://go-review.googlesource.com/122576 (for #23343)
The text was updated successfully, but these errors were encountered: