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

Open
rsc opened this Issue Aug 7, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@rsc
Contributor

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

runtime: make sure heapBitsBulkBarrier cannot be preempted
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-on: https://go-review.googlesource.com/13364
Reviewed-by: Austin Clements <austin@google.com>

@rsc rsc modified the milestones: Go1.6Early, Go1.5Maybe Aug 18, 2015

@aclements

This comment has been minimized.

Member

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