-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8372684: G1: Missing load_acquire() in G1 allocation path #28543
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
8372684: G1: Missing load_acquire() in G1 allocation path #28543
Conversation
Hi all, please review this change that changes some volatile atomics to the new `Atomic` construct, fixing some issue with missing load_acquire when allocating in `G1HeapRegion::par_allocate()`. That `load_acquire` seems necessary as when setting a new allocation region, there needs to be synchronization about the contents (top/end) of the heap region. Otherwise the allocating thread might get old/previous top values sent from the corresponding storestore (I changed to a `release_store()` in `G1AllocRegion::update_alloc_region()`. Similar issue exists in the handling of the retained regions. I also made the `G1AllocatorRegion::_dummy_region` Atomic; synchronization is necessary for a single `release_store` at initialization. No further synchronization is necessary (just using relaxed loads) as its contents are never changed afterwards. Testing: gha Thanks, Thomas
|
👋 Welcome back tschatzl! A progress list of the required criteria for merging this PR into |
|
@tschatzl This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 38 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. ➡️ To integrate this PR with the above commit message to the |
kimbarrett
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
|
Thanks @kimbarrett @kstefanj for your reviews /integrate |
|
Going to push as commit ef5e744.
Your commit was automatically rebased without conflicts. |
Hi all,
please review this change that changes some volatile atomics to the new
Atomicconstruct, fixing some issue with missing load_acquire when allocating inG1HeapRegion::par_allocate().That
load_acquireseems necessary as when setting a new allocation region, there needs to be synchronization about the contents (top/end) of the heap region. Otherwise the allocating thread might get old/previous top values sent from the corresponding storestore (I changed to arelease_store()inG1AllocRegion::update_alloc_region().Similar issue exists in the handling of the retained regions.
I also made the
G1AllocatorRegion::_dummy_regionAtomic; synchronization is necessary for a singlerelease_storeat initialization. No further synchronization is necessary (just using relaxed loads) as its contents are never changed afterwards.Performance testing, both manually on targeted benchmarks and a few general ones without differences.
Testing: gha, tier1-3
Thanks,
Thomas
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28543/head:pull/28543$ git checkout pull/28543Update a local copy of the PR:
$ git checkout pull/28543$ git pull https://git.openjdk.org/jdk.git pull/28543/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 28543View PR using the GUI difftool:
$ git pr show -t 28543Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28543.diff
Using Webrev
Link to Webrev Comment