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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: nowritebarrier not checked by SSA compiler #14784

Closed
aclements opened this issue Mar 11, 2016 · 2 comments
Closed

cmd/compile: nowritebarrier not checked by SSA compiler #14784

aclements opened this issue Mar 11, 2016 · 2 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@aclements
Copy link
Member

The //go:nowritebarrier and //go:nowritebarrierrec annotations in the runtime are not being checked in SSA mode.

For example, add sched.gfree = sched.gfree to any go:nowritebarrier function and compile the runtime. It should fail, but doesn't. Recompile with -gcflags -ssa=0 and it will correctly fail with "write barrier prohibited".

/cc @randall77 @dr2chase
@aclements aclements added this to the Go1.7 milestone Mar 11, 2016
@randall77
Copy link
Contributor

The check is easy to add in. But it is failing, SSA is generating a write barrier in runtime/mstkbar.go:208 where we store a slice to the heap:

    gp.stkbar = gp.stkbar[:len(gp.stkbar)+1]

When the frontend passes this assignment to SSA, it is marked as requiring a write barrier:

.   ASWB u(100) l(17067) tc(1)
.   .   DOTPTR u(2) l(17067) x(136+0) tc(1) assigned ARRAY-[]stkbar
.   .   .   NAME-runtime.gp u(1) a(true) g(2) l(17030) x(0+0) class(PPARAM) f(1) esc(no) tc(1) used(true) PTR64-*g
.   .   .   NAME-runtime.stkbar u(1) a(true) l(17067) x(0+0)
.   .   SLICE u(2) l(17067) tc(1) ARRAY-[]stkbar
.   .   .   DOTPTR u(2) l(17067) x(136+0) tc(1) ARRAY-[]stkbar
.   .   .   .   NAME-runtime.gp u(1) a(true) g(2) l(17030) x(0+0) class(PPARAM) f(1) esc(no) tc(1) used(true) PTR64-*g
.   .   .   .   NAME-runtime.stkbar u(1) a(true) l(17067) x(0+0)
.   .   .   KEY l(17067)
.   .   .   .   NAME-runtime.autotmp_2802 u(1) a(true) l(17067) x(0+0) class(PAUTO) esc(N) tc(1) assigned used(true) int

I guess there's some subsequent logic in the legacy compiler that removes the write barrier if it notices that the pointer being written is to the same object as the pointer that is already there. Might be nice if we pushed that logic up to before the SSA cutoff so it can be shared.

The only other occurrence is at mstkbar.go:233:

    gp.stkbar = gp.stkbar[:0]

@gopherbot
Copy link

CL https://golang.org/cl/20791 mentions this issue.

@golang golang locked and limited conversation to collaborators Mar 19, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
3 participants
@aclements @randall77 @gopherbot