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
8299032: Interface IN_NATIVE oop stores for C2 #11777
Conversation
👋 Welcome back eosterlund! A progress list of the required criteria for merging this PR into |
Thanks for the review, @stefank! |
@fisk 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 268 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 |
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.
Not a review, since I'm not sufficiently knowledgeable about C2 to really do justice to it.
Rather, a couple questions/comments.
We made a concerted effort to reduce/eliminate oops in native storage, instead using OopStorage entries. This kind of feels like backsliding on that effort. Why?
// Stores of oops to native memory not supported yet by BarrierSetC2::store_at_resolved | ||
// access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED); | ||
store_to_memory(control(), thread_obj_handle, arr, T_OBJECT, adr_type, MemNode::unordered); | ||
access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED); |
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.
Old code has a control()
constraint on the store. Is it okay to drop that?
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.
The first parameter to access_store_at, is the containing object, not the control (which might be different to the address). As for IN_NATIVE stores, there is no containing object, which is what the NULL denotes. In the backend, it does indeed attach the current control inside of BarrierSetC2::store_at_resolved.
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.
Thanks for the explanation.
It isn't a backsliding on that effort. This code is indeed using OopStorage. An OopHandle::replace uses IN_NATIVE stores. This is essentially an intrinsic that replaces the contents of an OopHandle, so similarly it should use an IN_NATIVE store for that. Having said that, perhaps it would have been more clear if there was a high level function of some sort with a name like oop_handle_replace containing the IN_NATIVE store? |
Oh, I see now. The |
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! Do not forget to update the copyright headers.
I checked the coverage of inline_native_setCurrentThread()
in tiers 1-3, and this function is only exercised by the serviceability and a few long-running, CTW-like test cases. We should probably extend test/hotspot/jtreg/compiler/intrinsics
with specific tests for Loom intrinsics (in a separate RFE).
Thanks for the review, @robcasloz! |
/integrate |
Going to push as commit e7fa150.
Your commit was automatically rebased without conflicts. |
Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11777/head:pull/11777
$ git checkout pull/11777
Update a local copy of the PR:
$ git checkout pull/11777
$ git pull https://git.openjdk.org/jdk pull/11777/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 11777
View PR using the GUI difftool:
$ git pr show -t 11777
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11777.diff