/ go Public
runtime: clearpools causes excessive STW1 time #22331
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Our application uses a large number of goroutines, mutexes, and defers. Using go 1.8.3 on linux amd64, we observed that the STW1 time is dominated by the
runtime.clearpoolsfunction in mgc.go. Here is an excerpt from the GC trace:
By instrumenting the runtime, we determined that, out of the 16ms STW1 time, 9.3ms was spent in the loop that disconnects
sched.sudogcachelinked list, and 6.7ms was spent in the loop that disconnects the linked lists in
sched.deferpool. These O(n) loops end up causing a very long pause.
I understand the reason for originally introducing the loops in #9110. However, looking at tip around the call sites of
freedefer, I couldn't see a case where a released object would still be referenced by a live pointer somewhere else in the system. Are these loops still really necessary?
FWIW, I replaced the loops with a simple zeroing of the heads of the linked lists, and test/fixedbugs/issue9110.go still passed.
I propose making these loops optional to avoid the excessive STW1 time, and enabling them only with a GODEBUG option for debugging purposes.
The text was updated successfully, but these errors were encountered: