Commit df2809f0 authored by Austin Clements's avatar Austin Clements

runtime: document that runtime.GC() blocks until GC is complete

runtime.GC() is intentionally very weakly specified. However, it is so
weakly specified that it's difficult to know that it's being used
correctly for its one intended use case: to ensure garbage collection
has run in a test that is garbage-sensitive. In particular, it is
unclear whether it is synchronous or asynchronous. In the old STW
collector this was essentially self-evident; short of queuing up a
garbage collection to run later, it had to be synchronous. However,
with the concurrent collector, there's evidence that people are
inferring that it may be asynchronous (e.g., issue #10986), as this is
both unclear in the documentation and possible in the implementation.

In fact, runtime.GC() runs a fully synchronous STW collection. We
probably don't want to commit to this exact behavior. But we can
commit to the essential property that tests rely on: that runtime.GC()
does not return until the GC has finished.

Change-Id: Ifc3045a505e1898ecdbe32c1f7e80e2e9ffacb5b
Reviewed-on: https://go-review.googlesource.com/10488Reviewed-by: default avatarKeith Randall <khr@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
parent 94df2050
......@@ -693,7 +693,8 @@ var work struct {
initialHeapLive uint64
}
// GC runs a garbage collection.
// GC runs a garbage collection and blocks until the garbage
// collection is complete.
func GC() {
startGC(gcForceBlockMode)
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment