Skip to content

G
golang
Switch branch/tag
  1. 06 Jan, 2015 5 commits
    • Russ Cox's avatar
      runtime, sync/atomic: add write barrier for atomic write of pointer · 7b4df8f0
      Russ Cox authored 
      Add write barrier to atomic operations manipulating pointers.

In general an atomic write of a pointer word may indicate racy accesses,
so there is no strictly safe way to attempt to keep the shadow copy
in sync with the real one. Instead, mark the shadow copy as not used.

Redirect sync/atomic pointer routines back to the runtime ones,
so that there is only one copy of the write barrier and shadow logic.
In time we might consider doing this for most of the sync/atomic
functions, but for now only the pointer routines need that treatment.

Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: I852936b9a111a6cb9079cfaf6bd78b43016c0242
Reviewed-on: https://go-review.googlesource.com/2066Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      7b4df8f0
    • Russ Cox's avatar
      runtime: change Gobuf.g to uintptr, not pointer · eafc482d
      Russ Cox authored 
      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/2065Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      eafc482d
    • Russ Cox's avatar
      runtime: add missing write barriers in append's copy of slice data · a73c1cef
      Russ Cox authored 
      Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: Ic8624401d7c8225a935f719f96f2675c6f5c0d7c
Reviewed-on: https://go-review.googlesource.com/2064Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      a73c1cef
    • Russ Cox's avatar
      runtime: add GODEBUG wbshadow for finding missing write barriers · dcec123a
      Russ Cox authored 
      This is the detection code. It works well enough that I know of
a handful of missing write barriers. However, those are subtle
enough that I'll address them in separate followup CLs.

GODEBUG=wbshadow=1 checks for a write that bypassed the
write barrier at the next write barrier of the same word.
If a bug can be detected in this mode it is typically easy to
understand, since the crash says quite clearly what kind of
word has missed a write barrier.

GODEBUG=wbshadow=2 adds a check of the write barrier
shadow copy during garbage collection. Bugs detected at
garbage collection can be difficult to understand, because
there is no context for what the found word means.
Typically you have to reproduce the problem with allocfreetrace=1
in order to understand the type of the badly updated word.

Change-Id: If863837308e7c50d96b5bdc7d65af4969bf53a6e
Reviewed-on: https://go-review.googlesource.com/2061Reviewed-by: 's avatarAustin Clements <austin@google.com>
      dcec123a
    • Josh Bleecher Snyder's avatar
      go/doc: propagate types from unexported constants · 3191a235
      Josh Bleecher Snyder authored 
      When constants were declared using unexported constants,
the type information was lost when those constants were filtered out.
This CL propagates the type information of unexported constants
so that it is available for display.

This is a follow-up to CL 144110044, which fixed this problem
specifically for _ constants.

Updates #5397.

Change-Id: I3f0c767a4007d88169a5634ab2870deea4e6a740
Reviewed-on: https://go-review.googlesource.com/2091Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      3191a235
  3. 05 Jan, 2015 11 commits
  5. 04 Jan, 2015 7 commits
  7. 03 Jan, 2015 2 commits
  9. 02 Jan, 2015 7 commits
  11. 01 Jan, 2015 6 commits
  13. 31 Dec, 2014 2 commits