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: spurious writebarriers emitted for global funcs #13901

Closed
DanielMorsing opened this issue Jan 10, 2016 · 6 comments
Closed

cmd/compile: spurious writebarriers emitted for global funcs #13901

DanielMorsing opened this issue Jan 10, 2016 · 6 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@DanielMorsing
Copy link
Contributor

gc emits write barriers when a global function is assigned, even though it is unnecessary

reproducer:

package foo

type t struct {
    x func() *t
}

func f() *t {
    g := new(t)
    g.x = f
    return g
}

Built with go build -gcflags '-d wb' blah.go, outputs ./blah.go:9: write barrier

I don't think there is any correctness issues with emitting the WB and I doubt the performance suffers for it, but I did get a spurious warning when doing some runtime dev.
@bradfitz bradfitz added this to the Unplanned milestone Jan 21, 2016
@bradfitz
Copy link
Contributor

/cc @aclements @randall77 @dr2chase

@aclements
Copy link
Member

Yes, you're right that it's safe to omit this write barrier, since we only care about heap -> heap pointer changes. We have various conditions for omitting write barriers if the slot is not in the heap, but I'm not aware of conditions for omitting write barriers if the pointer being written isn't a heap pointer. @randall77?

@DanielMorsing
Copy link
Contributor Author

Looks like it's a case of adding a case for PFUNC class nodes in this function https://golang.org/src/cmd/compile/internal/gc/walk.go#L2176

@randall77
Copy link
Contributor

Yes, that sounds right.
@aclements: We already have a few conditions on the pointer being written. nil, address of global, address of stack, ...

@aclements
Copy link
Member

Yes, I see. Does this not fall under the "address of global" exception because we haven't split up the two words at this point?

@randall77
Copy link
Contributor

A PFUNC eventually expands to the address of a global (which is why it is ok), but it is represented differently at this point in the compiler.

@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
Unplanned
Development

No branches or pull requests
5 participants
@bradfitz @DanielMorsing @aclements @randall77 @gopherbot