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
8272170: Missing memory barrier when checking active state for regions #6324
8272170: Missing memory barrier when checking active state for regions #6324
Conversation
|
@tschatzl This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 51 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
Thanks @albertnetymk @kstefanj for your reviews. |
Going to push as commit 35a831d.
Your commit was automatically rebased without conflicts. |
Hi all,
can I have reviews for this fix to memory visibility race where we miss to make sure that the
HeapRegion
pointer inHeapRegionManager::_regions
is visible before the "active"-check for thatHeapRegion
can return true?I.e. the problem is this (according to my understanding):
E.g. we first commit the memory, then create a
HeapRegion
instance which we properly guard with aStoreStore
before assigning it to the_regions
array. After that at the end we activate the regions (viaactivate_regions
), meaning that the contents of the newHeapRegion*
in the region table are valid.These bits in the
_active_regions
bitmap are put with memory barriers (viapar_set_range
).In
HeapRegionManager::par_iterate
, if we iterate over the region map, we first check whether the region is available in the_active_regions
bitmap, and then get and pass on the correspondingHeapRegion*
to the given closure.However there is no memory ordering between reading the available-bit in the
_active_regions
bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the_region
map itself, in effect passing anullptr
to the closure which isn't allowed. (Some details about the debugging session in the CR).The suggested fix is to ensure proper memory ordering in
is_available
, i.e. the loads must be ordered correctly.I did check a bit around the usage of this method and
is_unavailable
, but I do not think there is a similar issue.Testing: test crashed with a frequency of around 1/500, now passing 5k runs
Thanks,
Thomas
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6324/head:pull/6324
$ git checkout pull/6324
Update a local copy of the PR:
$ git checkout pull/6324
$ git pull https://git.openjdk.java.net/jdk pull/6324/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6324
View PR using the GUI difftool:
$ git pr show -t 6324
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6324.diff