aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAustin Clements <austin@google.com>2016-01-11 16:52:11 -0500
committerAustin Clements <austin@google.com>2016-01-12 02:00:55 +0000
commit7b1f055eb1fb5f600081563d3cb2f987fe400e46 (patch)
tree454e57b49f50ee6f8fa2a46606dd410bdf791843
parent352e287bf72229f274233a34e3382ad28d791d89 (diff)
downloadgo-7b1f055eb1fb5f600081563d3cb2f987fe400e46.tar.gz
go-7b1f055eb1fb5f600081563d3cb2f987fe400e46.zip
runtime: remove out-of-date comment
It used to be the case that repeatedly getting one GC pointer and enqueuing one GC pointer could cause contention on the work buffers as each operation passed over the boundary of a work buffer. As of b6c0934, we use a two buffer cache that prevents this sort of contention. Change-Id: I4f1111623f76df9c5493dd9124dec1e0bfaf53b7 Reviewed-on: https://go-review.googlesource.com/18532 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-rw-r--r--src/runtime/mgcmark.go6
1 files changed, 0 insertions, 6 deletions
diff --git a/src/runtime/mgcmark.go b/src/runtime/mgcmark.go
index 91b76a8a67..720fd72ada 100644
--- a/src/runtime/mgcmark.go
+++ b/src/runtime/mgcmark.go
@@ -835,12 +835,6 @@ func gcDrain(gcw *gcWork, flags gcDrainFlags) {
// work barrier reached or tryGet failed.
break
}
- // If the current wbuf is filled by the scan a new wbuf might be
- // returned that could possibly hold only a single object. This
- // could result in each iteration draining only a single object
- // out of the wbuf passed in + a single object placed
- // into an empty wbuf in scanobject so there could be
- // a performance hit as we keep fetching fresh wbufs.
scanobject(b, gcw)
// Flush background scan work credit to the global