8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address()#25324
8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address()#25324minborg wants to merge 14 commits into
Conversation
|
👋 Welcome back pminborg! A progress list of the required criteria for merging this PR into |
|
@minborg 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 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
| } | ||
|
|
||
| boolean pending = false; | ||
| NIO_ACCESS.acquireSession(buf); |
There was a problem hiding this comment.
Here, we acquire the session after we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.
There was a problem hiding this comment.
Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these.
There was a problem hiding this comment.
Never mind, I see that there are already acquireSession/releaseSession calls when the ByteBuffer objects are accessed.
Webrevs
|
|
We need to audit the tests for the APIs that take a byte buffer to ensure that we have tests to exercise these APIs with buffers that are views on a memory segment. That would help identify any bugs. The temporary buffer cache is internal so I think better to separate from this JBS issue and PR as these cases cannot be views on a memory segment. Future work to re-implement the temporary buffer cache can re-visit this. |
|
A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment? |
| ioCache.remove(overlapped); | ||
|
|
||
| } finally { | ||
| NIO_ACCESS.releaseSession(buf); |
There was a problem hiding this comment.
I thin the change to WindowsAsynchronousFileChannel will need more than one reviewer as the I/O operation may complete on a different thread to the one that it was initiated on.
|
/reviewers 2 |
I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed. |
Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests. |
I've created https://bugs.openjdk.org/browse/JDK-8357466. There are some missing fields, I hope someone can fill them in. |
valeriepeng
left a comment
There was a problem hiding this comment.
Security source changes look fine.
| } | ||
|
|
||
| boolean pending = false; | ||
| IOUtil.acquireScope(buf, true); |
There was a problem hiding this comment.
Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.
There was a problem hiding this comment.
WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good.
There was a problem hiding this comment.
Good, thanks for checking.
| ioCache.remove(overlapped); | ||
|
|
||
| } finally { | ||
| IOUtil.releaseScope(buf); |
There was a problem hiding this comment.
I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted.
TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR.
There was a problem hiding this comment.
Sounds like a good idea: https://bugs.openjdk.org/browse/JDK-8357847
|
/reviewers 1 I am reverting to 1 reviewer, as we have removed the asynchronous Windows class. |
|
/integrate |
|
Going to push as commit d4b923d.
Your commit was automatically rebased without conflicts. |
This PR proposes to use
JavaNioAccess::getBufferAdressrather thanDirectBuffer::addressso thatBufferinstances backed by MemorySegment instances can be used in classes that were not covered by #25321This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324$ git checkout pull/25324Update a local copy of the PR:
$ git checkout pull/25324$ git pull https://git.openjdk.org/jdk.git pull/25324/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25324View PR using the GUI difftool:
$ git pr show -t 25324Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25324.diff
Using Webrev
Link to Webrev Comment