-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8336768: Allow captureCallState and critical linker options to be combined #22327
Conversation
👋 Welcome back jvernee! A progress list of the required criteria for merging this PR into |
@JornVernee 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 168 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 |
@JornVernee The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
if (invData.capturedStateMask() != 0) { | ||
capturedState = SharedUtils.checkCaptureSegment((MemorySegment) args[argStart++]); | ||
if (!invData.allowsHeapAccess) { | ||
SharedUtils.checkNative(capturedState); |
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.
I noticed that this check was missing in the fallback linker, and we were actually crashing when a heap segment was passed as the capture state segment. I've added a new test case that checks that this works as well.
/csr |
@JornVernee has indicated that a compatibility and specification (CSR) request is needed for this pull request. @JornVernee please create a CSR request for issue JDK-8336768 with the correct fix version. This pull request cannot be integrated until the CSR request is approved. |
Webrevs
|
if (methodType.parameterType(0) != long.class) { | ||
throw new AssertionError("Address expected as first param: " + methodType); | ||
} | ||
int checkIdx = 1; | ||
if ((needsReturnBuffer && methodType.parameterType(checkIdx++) != long.class) | ||
|| (savedValueMask != 0 && methodType.parameterType(checkIdx) != long.class)) { | ||
|| (savedValueMask != 0 && |
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.
Maybe this routine is getting too complex and it would be better to split the checks (and add some comments) ? E.g. we need to check that if there's a return buffer, a certain low-level argument is long
and, if there's need to capture state, we either have long
, or an Object,long
pair.
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.
Perhaps, even throwing different assertion error might help
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.
Yeah... I'll split this up a bit to make it more readable.
@@ -195,6 +195,10 @@ public boolean needsTransition() { | |||
return !linkerOptions.isCritical(); | |||
} | |||
|
|||
public boolean usingAddressPairs() { |
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.
Nit: Copyright years
@@ -90,10 +90,11 @@ private static boolean tryLoadLibrary() { | |||
* @see jdk.internal.foreign.abi.CapturableState | |||
*/ | |||
static void doDowncall(MemorySegment cif, MemorySegment target, MemorySegment retPtr, MemorySegment argPtrs, | |||
MemorySegment capturedState, int capturedStateMask, | |||
Object captureStateHeapBase, MemorySegment capturedState, int capturedStateMask, |
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.
I find it a bit weird that this method is receiving both the captured segment base and the segment itself. It almost seems as if the checks we do in FallbackLinker
should be done here?
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.
I see what you mean, and I agree it looks a bit strange. but we also pass the array of heap bases separately here (which is more or less a forced move due to how the libffi API works). So, I think the current code is more inline with that. The LibFallback
class is only supposed to be a thin wrapper around the native methods in fallbackLinker.c
. The actual logic is all in FallbackLinker
.
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 - left some minor comments
/integrate |
Going to push as commit 8cad043.
Your commit was automatically rebased without conflicts. |
@JornVernee Pushed as commit 8cad043. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
I've already tested this and it works great. Thanks! |
Allow
captureCallState
andcritical(true)
linker options to be combined. This allows passing a Java array to capture call state.One caveat is that the linker expects the memory to be aligned, which means that at least an
int[]
has to be used (i.e.byte[]
will no work).This patch contains two implementations: one for the linkers that use
CallingSequenceBuilder
. That one is quite straight-forward, as we can just mimic what we already do for other memory segment arguments, but also for the capture state segment. i.e. split it into base and offset, and pass that down to our downcall stub. The stub will then add the offset and oop together, and pass use the resulting address to write to.The other implementation is for the fallback linker. This handles the capture state a little differently, but essentially currently just passes the native address to the back end for the native code to write the captured state into. I've just added another heap base parameter for that capture state segment to the back end, which is then turned into a native address using JNI's
GetPrimitiveArrayCritical
, similarly to what we do for other heap segments.Testing:
jdk_foreign
test suite.Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22327/head:pull/22327
$ git checkout pull/22327
Update a local copy of the PR:
$ git checkout pull/22327
$ git pull https://git.openjdk.org/jdk.git pull/22327/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22327
View PR using the GUI difftool:
$ git pr show -t 22327
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22327.diff
Using Webrev
Link to Webrev Comment