From 385ea724102f989e675ff210f360fbee085044e7 Mon Sep 17 00:00:00 2001
From: Austin Clements
- TODO(austin): give update.
+
+ Library functions that used to trigger stop-the-world garbage
+ collection now trigger concurrent garbage collection.
+
+ Specifically,
+ The
+
+ Large object allocation performance is significantly improved in
+ applications using large (>50GB) heaps containing many large
+ objects.
+
+ The Garbage Collector
-runtime.GC
,
+ debug.SetGCPercent
,
+ and
+ debug.FreeOSMemory
,
+ now trigger concurrent garbage collection, blocking only the calling
+ goroutine until the garbage collection is done.
+debug.SetGCPercent
+ function only triggers a garbage collection if one is immediately
+ necessary because of the new GOGC value.
+ This makes it possible to adjust GOGC on-the-fly.
+runtime.ReadMemStats
+ function now takes less than 100µs even for very large heaps.
Core library
@@ -482,10 +509,6 @@ type T1 = T2
TODO: https://golang.org/cl/29341: use cpuset_getaffinity for runtime.NumCPU() on FreeBSD
- TODO: https://golang.org/cl/34937: make ReadMemStats STW for < 25µs -
-TODO: https://golang.org/cl/35710: make time correctly update on Wine
@@ -498,10 +521,6 @@ type T1 = T2 TODO: https://golang.org/cl/37441: make complex division c99 compatible -- TODO: https://golang.org/cl/37520: make runtime.GC() trigger a concurrent GC -
-TODO: https://golang.org/cl/37726: strongly encourage CallersFrames with the result of Callers
@@ -520,18 +539,6 @@ type T1 = T2 -- TODO: https://golang.org/cl/34013: don't run a GC when setting SetGCPercent negative -
- -- TODO: https://golang.org/cl/39835: don't trigger a GC on SetGCPercent -
- --- 2.48.1