| commit | bfb1f563716f513b1c58883c7217f468c53a0f1a | [log] [tgz] |
|---|---|---|
| author | Michael Anthony Knyszek <mknyszek@google.com> | Thu Apr 11 20:33:20 2024 +0000 |
| committer | Michael Knyszek <mknyszek@google.com> | Thu Apr 11 21:23:08 2024 +0000 |
| tree | c25763f36a62c666fd593a0b20a7fe5e1d868564 | |
| parent | 1843464f014c946c1663de76249267486887626f [diff] |
internal/trace/v2: make TestGCStress less random Currently TestGCStress' main loop allocates a randomly-sized byte slice in a loop. On the windows-386 builder, it looks like the following is happening. In such heavily-allocating scenarios, the test seems to be able to outrun the GC. This is a known issue on all platforms, but it looks to me like there may be a real issue with mark termination. (Fixing that is outside the scope of this change, but relevant here.) Furthermore, while the test is ramping up, the pacer is taking time to acclimate to the high allocation rate. This is probably made worse due to the coarse time granularity on Windows, since the pacer relies on accurate time measurements. Because the pacer is ramping up, it isn't starting early enough, causing a lot of memory to get allocated black and inflate the live heap size. This happens for more than one cycle. Last but not least, because the core allocating loop of this test allocates randomly-sized byte slices, we could just get unlucky and inflate the live heap by much more sometimes. Furthermore, the randomness creates chaos for the pacer that is totally unnecessary for this test. Although I couldn't reproduce the issue we're seeing on the trybots in a gomote, I *could* reproduce memory spikes in general. These memory spikes always occurred before the pacer had a chance to "warm up," in the first two cycles after the heavy allocating begins. I believe the flakiness we're seeing is all of these factors lining up, because if I just make the size of the allocated byte slices smaller and non-random, I can no longer reproduce the memory spikes. This change implements this as a fix in the hope that it'll resolve the flakiness. Fixes #66624. Change-Id: I478d45e7c600e5aee4b21dbe831e1f287284f5e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/578319 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 4.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Official binary distributions are available at https://go.dev/dl/.
After downloading a binary release, visit https://go.dev/doc/install for installation instructions.
If a binary distribution is not available for your combination of operating system and architecture, visit https://go.dev/doc/install/source for source installation instructions.
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines at https://go.dev/doc/contribute.
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://go.dev/wiki/Questions for a list of places to ask questions about the Go language.