aboutsummaryrefslogtreecommitdiff
path: root/src/sync/atomic
diff options
context:
space:
mode:
authorRuss Cox <rsc@golang.org>2014-12-22 22:43:49 -0500
committerRuss Cox <rsc@golang.org>2015-01-06 00:26:54 +0000
commiteafc482d4f091c4ddd2178098d94831d1e2f25ab (patch)
treed0f42fbc5ab5f042fa12dfa70df2deac8d1faf77 /src/sync/atomic
parenta73c1cef070a33527c869d36a763ea265f689fe3 (diff)
downloadgo-eafc482d4f091c4ddd2178098d94831d1e2f25ab.tar.xz
runtime: change Gobuf.g to uintptr, not pointer
The Gobuf.g goroutine pointer is almost always updated by assembly code. In one of the few places it is updated by Go code - func save - it must be treated as a uintptr to avoid a write barrier being emitted at a bad time. Instead of figuring out how to emit the write barriers missing in the assembly manipulation, change the type of the field to uintptr, so that it does not require write barriers at all. Goroutine structs are published in the allg list and never freed. That will keep the goroutine structs from being collected. There is never a time that Gobuf.g's contain the only references to a goroutine: the publishing of the goroutine in allg comes first. Goroutine pointers are also kept in non-GC-visible places like TLS, so I can't see them ever moving. If we did want to start moving data in the GC, we'd need to allocate the goroutine structs from an alternate arena. This CL doesn't make that problem any worse. Found with GODEBUG=wbshadow=1 mode. Eventually that will run automatically, but right now it still detects other missing write barriers. Change-Id: I85f91312ec3e0ef69ead0fff1a560b0cfb095e1a Reviewed-on: https://go-review.googlesource.com/2065 Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Diffstat (limited to 'src/sync/atomic')
0 files changed, 0 insertions, 0 deletions