]> Cypherpunks repositories - gostls13.git/commit
runtime: disentangle next_gc from GC trigger
authorAustin Clements <austin@google.com>
Thu, 15 Sep 2016 18:08:04 +0000 (14:08 -0400)
committerAustin Clements <austin@google.com>
Mon, 26 Sep 2016 22:00:44 +0000 (22:00 +0000)
commitec9c84c8840124b4cf883ab08f6c2dc6baf20732
tree7fd1ea471cf7c0f0b22c553dc5db17f68108087b
parent196df6f0c9ddd7043984cdf5d7becfb647ec1a31
runtime: disentangle next_gc from GC trigger

Back in Go 1.4, memstats.next_gc was both the heap size at which GC
would trigger, and the size GC kept the heap under. When we switched
to concurrent GC in Go 1.5, we got somewhat confused and made this
variable the trigger heap size, while gcController.heapGoal became the
goal heap size.

memstats.next_gc is exposed to the user via MemStats.NextGC, while
gcController.heapGoal is not. This is unfortunate because 1) the heap
goal is far more useful for diagnostics, and 2) the trigger heap size
is just part of the GC trigger heuristic, which means it wouldn't be
useful to an application even if it tried to use it.

We never noticed this mess because MemStats.NextGC is practically
undocumented. Now that we're trying to document MemStats, it became
clear that this field had diverged from its original usefulness.

Clean up this mess by shuffling things back around so that next_gc is
the goal heap size and the new (unexposed) memstats.gc_trigger field
is the trigger heap size. This eliminates gcController.heapGoal.

Updates #15849.

Change-Id: I2cbbd43b1d78bdf613cb43f53488bd63913189b7
Reviewed-on: https://go-review.googlesource.com/29270
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
src/runtime/mgc.go
src/runtime/mstats.go