runtime: gcMarkRootCheck contributes significantly to mark termination time #14419
Comments
|
Confirmed. This mark termination latency regression happened in 82d14d7 when I introduced gcMarkRootCheck. The cost is ~30ns per goroutine, similar to #14420. I could simply remove it. I'm a bit weary of doing that because it's a good check. If I lift gcscandone into a contiguous array as I proposed in #14420, I suspect the check will be roughly free (and now I have the benchmarks to confirm that :) |
|
It looks like gcMarkRootCheck is only about 10ns of that 30ns per goroutine. I'm not entirely sure where the rest of it is coming from, but I have some ideas for how I might be able to restructure mark termination so there are no O(# goroutines) steps at all. (That's obviously not for Go 1.6.1, especially since it depends on concurrent stack shrinking. :) |
|
CL https://golang.org/cl/20148 mentions this issue. |
|
CL https://golang.org/cl/22044 mentions this issue. |
gcMarkRootCheck takes ~10ns per goroutine. This is just a debugging check, so disable it (plus, if something is going to go wrong, it's more likely to go wrong during concurrent mark). We may be able to re-enable this later, or move it to after we've started the world again. (But not for 1.6.x.) For 1.6.x. Fixes #14419. name / 95%ile-time/markTerm old new delta 500kIdleGs-12 24.0ms ± 0% 18.9ms ± 6% -21.46% (p=0.000 n=15+20) Change-Id: Idb2a2b1771449de772c159ef95920d6df1090666 Reviewed-on: https://go-review.googlesource.com/20148 Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/22044 Reviewed-by: Austin Clements <austin@google.com>
When profiling the reproducer for #14406 with "go version go1.6 linux/amd64", stack shrinking off, and numactl disabling memory migration, I see calls to
runtime.gcMarkRootCheckon 12% of the stacks that includeruntime.gcMark. The comment for the function indicates that it's for debugging—is that for producing higher-quality bug reports if there's memory corruption or incorrect GC behavior in production releases, or for debugging while writing the GC?@aclements
The text was updated successfully, but these errors were encountered: