go/src/runtime/atomic_pointer.go, branch json-isValidNumber

runtime: remove the restriction that write barrier ptrs come in pairs

2023-02-17T22:19:26Z

Future CLs will remove the invariant that pointers are always put in the write barrier in pairs. The behavior of the assembly code changes a bit, where instead of writing the pointers unconditionally and then checking for overflow, check for overflow first and then write the pointers. Also changed the write barrier flush function to not take the src/dst as arguments. Change-Id: I2ef708038367b7b82ea67cbaf505a1d5904c775c Reviewed-on: https://go-review.googlesource.com/c/go/+/447779 Run-TryBot: Keith Randall Reviewed-by: Cherry Mui Reviewed-by: Michael Knyszek TryBot-Bypass: Keith Randall

runtime: reimplement GODEBUG=cgocheck=2 as a GOEXPERIMENT

2023-02-16T00:16:24Z

Move this knob from a binary-startup thing to a build-time thing. This will enable followon optmizations to the write barrier. Change-Id: Ic3323348621c76a7dc390c09ff55016b19c43018 Reviewed-on: https://go-review.googlesource.com/c/go/+/447778 Reviewed-by: Michael Knyszek Run-TryBot: Keith Randall TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui

runtime/internal/atomic: add write barrier-enabled pointer atomics

2022-10-18T14:48:54Z

UnsafePointer.Store, UnsafePointer.CompareAndSwap were missing, although .StoreNoWB and .CompareAndSwapNoWB existed. Same for Pointer[T}. Do the linkname tricks necessary to add those methods. Change-Id: I925ee27673288accb15ebe93898f9eb01ab46a98 Reviewed-on: https://go-review.googlesource.com/c/go/+/443379 Auto-Submit: Russ Cox Reviewed-by: Austin Clements Run-TryBot: Russ Cox TryBot-Result: Gopher Robot

runtime: remove unused function casp

2018-08-22T22:43:12Z

Change-Id: I7c9c83ba236e1050e04377a7591fef7174df698b Reviewed-on: https://go-review.googlesource.com/130415 Run-TryBot: Ian Lance Taylor TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick

runtime: eliminate all writebarrierptr* calls

2018-02-13T16:34:45Z

Calls to writebarrierptr can simply be actual pointer writes. Calls to writebarrierptr_prewrite need to go through the write barrier buffer. Updates #22460. Change-Id: I92cee4da98c5baa499f1977563757c76f95bf0ca Reviewed-on: https://go-review.googlesource.com/92704 Run-TryBot: Austin Clements Reviewed-by: Rick Hudson

runtime: perform write barrier before pointer write

2016-10-28T20:47:52Z

Currently, we perform write barriers after performing pointer writes. At the moment, it simply doesn't matter what order this happens in, as long as they appear atomic to GC. But both the hybrid barrier and ROC are going to require a pre-write write barrier. For the hybrid barrier, this is important because the barrier needs to observe both the current value of the slot and the value that will be written to it. (Alternatively, the caller could do the write and pass in the old value, but it seems easier and more useful to just swap the order of the barrier and the write.) For ROC, this is necessary because, if the pointer write is going to make the pointer reachable to some goroutine that it currently is not visible to, the garbage collector must take some special action before that pointer becomes more broadly visible. This commits swaps pointer writes around so the write barrier occurs before the pointer write. The main subtlety here is bulk memory writes. Currently, these copy to the destination first and then use the pointer bitmap of the destination to find the copied pointers and invoke the write barrier. This is necessary because the source may not have a pointer bitmap. To handle these, we pass both the source and the destination to the bulk memory barrier, which uses the pointer bitmap of the destination, but reads the pointer values from the source. Updates #17503. Change-Id: I78ecc0c5c94ee81c29019c305b3d232069294a55 Reviewed-on: https://go-review.googlesource.com/31763 Reviewed-by: Rick Hudson

sync/atomic: don't atomically write pointers twice

2016-04-14T21:13:26Z

sync/atomic.StorePointer (which is implemented in runtime/atomic_pointer.go) writes the pointer twice (through two completely different code paths, no less). Fix it to only write once. Change-Id: Id3b2aef9aa9081c2cf096833e001b93d3dd1f5da Reviewed-on: https://go-review.googlesource.com/21999 Run-TryBot: Austin Clements TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick Reviewed-by: Michael Matloob Reviewed-by: Rick Hudson

runtime: make sync_atomic_SwapPointer signature match sync/atomic

2016-04-14T21:13:23Z

SwapPointer is declared as func SwapPointer(addr *unsafe.Pointer, new unsafe.Pointer) (old unsafe.Pointer) in sync/atomic, but defined in the runtime (where it's actually implemented) as func sync_atomic_SwapPointer(ptr unsafe.Pointer, new unsafe.Pointer) unsafe.Pointer Make ptr a *unsafe.Pointer in the runtime definition to match the type in sync/atomic. Change-Id: I99bab651b995001bbe54f9e790fdef2417ef0e9e Reviewed-on: https://go-review.googlesource.com/21998 Run-TryBot: Austin Clements TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick Reviewed-by: Michael Matloob

runtime/internal/atomic: rename Storep1 to StorepNoWB

2016-04-13T19:17:25Z

Make it clear that the point of this function stores a pointer *without* a write barrier. sed -i -e 's/Storep1/StorepNoWB/' $(git grep -l Storep1) Updates #15270. Change-Id: Ifad7e17815e51a738070655fe3b178afdadaecf6 Reviewed-on: https://go-review.googlesource.com/21994 Reviewed-by: Brad Fitzpatrick Reviewed-by: Michael Matloob

runtime/internal/atomic: remove write barrier from Storep1 on s390x

2016-04-13T16:06:51Z

atomic.Storep1 is not supposed to invoke a write barrier (that's what atomicstorep is for), but currently does on s390x. This causes a panic in runtime.mapzero when it tries to use atomic.Storep1 to store what's actually a scalar. Fix this by eliminating the write barrier from atomic.Storep1 on s390x. Also add some documentation to atomicstorep to explain the difference between these. Fixes #15270. Change-Id: I291846732d82f090a218df3ef6351180aff54e81 Reviewed-on: https://go-review.googlesource.com/21993 Reviewed-by: Brad Fitzpatrick Run-TryBot: Austin Clements Reviewed-by: Michael Munday