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

Jump to bottom

runtime: check for no preemption during write barrier #12069

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

runtime: check for no preemption during write barrier #12069

rsc opened this issue Aug 7, 2015 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone
Unplanned

Comments

@rsc
Copy link
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
@rsc
runtime: make sure heapBitsBulkBarrier cannot be preempted
3ae1704 
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
Copy link
Member

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
@rsc rsc removed their assignment Jun 23, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Milestone
Unplanned
Development

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