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

runtime: check for no preemption during write barrier #12069

rsc opened this issue Aug 7, 2015 · 1 comment

runtime: check for no preemption during write barrier #12069

rsc opened this issue Aug 7, 2015 · 1 comment


Copy link

@rsc rsc commented Aug 7, 2015

Check that write barrier routines cannot be preempted.

Go1.5Maybe because we may have time to add the checks to a local copy
and at least verify that there aren't any missing go:nosplits that are needed
(or add the ones that are needed) in the release branch.

@rsc rsc self-assigned this Aug 7, 2015
@rsc rsc added this to the Go1.5Maybe milestone Aug 7, 2015
rsc added a commit that referenced this issue Aug 7, 2015
Changes the torture test in #12068 from failing about 1/10 times
to not failing in almost 2,000 runs.

This was only happening in -race mode because functions are
bigger in -race mode, so a few of the helpers for heapBitsBulkBarrier
were not being inlined, and they were not marked nosplit,
so (only in -race mode) the write barrier was being preempted by GC,
causing missed pointer updates.

Filed issue #12069 for diagnosis of any other similar errors.

Fixes #12068.

Change-Id: Ic174d9b050ba278b18b08ab0d85a73c33bd5b175
Reviewed-by: Austin Clements <>
@rsc rsc modified the milestones: Go1.6Early, Go1.5Maybe Aug 18, 2015
Copy link

@aclements aclements commented Nov 10, 2015

To be clear, this is about things like typedmemmove, not the regular write barrier, which runs on the system stack and hence is not preemptible.

It seems like the way to do this is to add a new "go:nopreempt" annotation that's like a recursive nosplit and replace nosplits with nopreempts where that's what we really mean. One sticking point may be functions that increment mp.locks or set mp.preemptoff that must not be preempted before this point, but can grow the stack once they've dynamically disallowed preemption. Maybe for these we just keep using nosplit.

@rsc rsc modified the milestones: Go1.6Maybe, Go1.6Early Nov 23, 2015
@rsc rsc modified the milestones: Unplanned, Go1.6Maybe Dec 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.