Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: sync/atomic.SwapPointer arguments escape for the wrong reason #15283

Open
aclements opened this issue Apr 13, 2016 · 4 comments
Open
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@aclements
Copy link
Member

In the implementation of sync/atomic.SwapPointer (which is in runtime/atomic_pointer.go), there's nothing that causes the "new" argument to escape, even though it needs to (because you could be swapping it in to a global). The compiler agrees:

$ go build -gcflags "-m -m" -a runtime |& grep sync_atomic_SwapPointer                                                                     
runtime/atomic_pointer.go:58: sync_atomic_SwapPointer ptr does not escape
runtime/atomic_pointer.go:58: sync_atomic_SwapPointer new does not escape

However, you can't actually tickle this. For example, in principle the following program should sneak the address of stack variable y into a global variable:

package main

import (
    "sync/atomic"
    "unsafe"
)

var x unsafe.Pointer

func main() {
    var y int
    z := unsafe.Pointer(&y)
    atomic.SwapPointer(&x, z)
}

But it doesn't!

$ go build -gcflags "-m -m" x.go
# command-line-arguments                        
./aesc.go:13: &x escapes to heap
./aesc.go:13:   from &x (passed to function[unknown]) at ./aesc.go:13
./aesc.go:11: moved to heap: y
./aesc.go:12: &y escapes to heap
./aesc.go:12:   from z (assigned) at ./aesc.go:12
./aesc.go:12:   from z (passed to function[unknown]) at ./aesc.go:12

This happens to work right now, but for the wrong reason: because SwapPointer is defined in the runtime and we use a "go:linkname" comment to expose it from sync/atomic, there's no escape information at all when the test program calls SwapPointer (hence the "passed to function[unknown]"), so the compiler conservatively assumes everything escapes. (In fact, the first argument doesn't have to escape and we have annotations in the runtime to that effect, but they never make it through.)

This all seems very fragile.

/cc @dr2chase @randall77

@bradfitz bradfitz added this to the Go1.7 milestone Apr 14, 2016
@rsc
Copy link
Contributor

rsc commented May 17, 2016

Fragile, but not broken.

@rsc rsc modified the milestones: Go1.8, Go1.7 May 17, 2016
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 11, 2016
@rsc rsc modified the milestones: Go1.9, Go1.8 Oct 21, 2016
@randall77 randall77 modified the milestones: Go1.10, Go1.9 Jun 6, 2017
@mdempsky mdempsky modified the milestones: Go1.10, Go1.11 Nov 29, 2017
@mdempsky
Copy link
Member

Still fragile, but still not broken.

@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018
@mdempsky
Copy link
Member

Still fragile, but still not broken with newescape too.

@gopherbot
Copy link

Change https://golang.org/cl/172420 mentions this issue: test: add escape regress tests for runtime and sync atomics

gopherbot pushed a commit that referenced this issue Apr 17, 2019
There weren't any tests to make sure these work correctly, and this
led to escape analysis regressions in both linux/s390x and js/wasm.

The underlying issue that cmd/compile is only getting some of these
correct because escape analysis doesn't understand //go:linkname is
still present, but at least this addresses the fragility aspect.

Updates #15283.

Change-Id: I546aee1899d098b2e3de45e9b33c3ca22de485f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/172420
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

7 participants