aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/mcache.go
diff options
context:
space:
mode:
authorAustin Clements <austin@google.com>2015-03-30 18:01:32 -0400
committerAustin Clements <austin@google.com>2015-04-06 21:28:13 +0000
commitd7e0ad4b82c007a8c8d57fcd74b41dcd8aa9ea3c (patch)
tree1cd24382e8af8db3b18cb1dffeed6921360c2c98 /src/runtime/mcache.go
parent50a66562a067504c9a21a0ccc00f209ac78166ca (diff)
downloadgo-d7e0ad4b82c007a8c8d57fcd74b41dcd8aa9ea3c.tar.gz
go-d7e0ad4b82c007a8c8d57fcd74b41dcd8aa9ea3c.zip
runtime: introduce heap_live; replace use of heap_alloc in GC
Currently there are two main consumers of memstats.heap_alloc: updatememstats (aka ReadMemStats) and shouldtriggergc. updatememstats recomputes heap_alloc from the ground up, so we don't need to keep heap_alloc up to date for it. shouldtriggergc wants to know how many bytes were marked by the previous GC plus how many bytes have been allocated since then, but this *isn't* what heap_alloc tracks. heap_alloc also includes objects that are not marked and haven't yet been swept. Introduce a new memstat called heap_live that actually tracks what shouldtriggergc wants to know and stop keeping heap_alloc up to date. Unlike heap_alloc, heap_live follows a simple sawtooth that drops during each mark termination and increases monotonically between GCs. heap_alloc, on the other hand, has much more complicated behavior: it may drop during sweep termination, slowly decreases from background sweeping between GCs, is roughly unaffected by allocation as long as there are unswept spans (because we sweep and allocate at the same rate), and may go up after background sweeping is done depending on the GC trigger. heap_live simplifies computing next_gc and using it to figure out when to trigger garbage collection. Currently, we guess next_gc at the end of a cycle and update it as we sweep and get a better idea of how much heap was marked. Now, since we're directly tracking how much heap is marked, we can directly compute next_gc. This also corrects bugs that could cause us to trigger GC early. Currently, in any case where sweep termination actually finds spans to sweep, heap_alloc is an overestimation of live heap, so we'll trigger GC too early. heap_live, on the other hand, is unaffected by sweeping. Change-Id: I1f96807b6ed60d4156e8173a8e68745ffc742388 Reviewed-on: https://go-review.googlesource.com/8389 Reviewed-by: Russ Cox <rsc@golang.org>
Diffstat (limited to 'src/runtime/mcache.go')
-rw-r--r--src/runtime/mcache.go2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/runtime/mcache.go b/src/runtime/mcache.go
index 9ff4259ce9..14748a43f1 100644
--- a/src/runtime/mcache.go
+++ b/src/runtime/mcache.go
@@ -12,7 +12,7 @@ type mcache struct {
// The following members are accessed on every malloc,
// so they are grouped here for better caching.
next_sample int32 // trigger heap sample after allocating this many bytes
- local_cachealloc intptr // bytes allocated (or freed) from cache since last lock of heap
+ local_cachealloc intptr // bytes allocated from cache since last lock of heap
// Allocator cache for tiny objects w/o pointers.
// See "Tiny allocator" comment in malloc.go.
tiny unsafe.Pointer