As far as I can tell, this test suffers from #52433. For some reason,
this seems to become more of a problem on the windows/386 than anywhere
else. This CL is an attempt at a mitigation by slowing down the
allocation rate by inserting runtime.Gosched call in the inner loop. It
also cuts the iteration count which should help too (as less memory is
allocated in total), but the main motivation is to make sure the test
doesn't take too long to run.
Fixes#49564.
Change-Id: I8cc622b06a69cdfa66f680a30e1ccf334eea2164
Reviewed-on: https://go-review.googlesource.com/c/go/+/408825
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Update the test in test/heapsampling.go to more thoroughly validate heap sampling.
Lower the sampling rate on the test to ensure allocations both smaller and
larger than the sampling rate are tested.
Tighten up the validation check to a 10% difference between the unsampled and correct value.
Because of the nature of random sampling, it is possible that the unsampled value fluctuates
over that range. To avoid flakes, run the experiment three times and only report an issue if the
same location consistently falls out of range on all experiments.
This tests the sampling fix in cl/158337.
Change-Id: I54a709e5c75827b8b1c2d87cdfb425ab09759677
GitHub-Last-Rev: 7c04f12603
GitHub-Pull-Request: golang/go#26944
Reviewed-on: https://go-review.googlesource.com/c/go/+/129117
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The heap profile is only guaranteed to be up-to-date after two GC
cycles, so force two GCs instead of just one.
Updates #13098.
Change-Id: I4fb9287b698f4a3b90b8af9fc6a2efb3b082bfe5
Reviewed-on: https://go-review.googlesource.com/16848
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The heapsampling.go test occasionally fails on some architectures
because it finds zero heap samples in main.alloc. This happens because
the byte and object counts are only updated at a GC. Hence, if a GC
happens part way through allocInterleaved, but then doesn't happen
after we start calling main.alloc, checkAllocations will see buckets
for the lines in main.alloc (which are created eagerly), but the
object and byte counts will be zero.
Fix this by forcing a GC to update the profile before we collect it.
Fixes#13098.
Change-Id: Ia7a9918eea6399307f10499dd7abefd4f6d13cf6
Reviewed-on: https://go-review.googlesource.com/16846
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The current heap sampling introduces some bias that interferes
with unsampling, producing unexpected heap profiles.
The solution is to use a Poisson process to generate the
sampling points, using the formulas described at
https://en.wikipedia.org/wiki/Poisson_process
This fixes#12620
Change-Id: If2400809ed3c41de504dd6cff06be14e476ff96c
Reviewed-on: https://go-review.googlesource.com/14590
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
