-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8345181: (ch) Windows asynchronous channels may return temporary direct buffers to the buffer cache twice (win) #22554
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
Conversation
…ct buffers to the buffer cache twice (win)
👋 Welcome back bpb! A progress list of the required criteria for merging this PR into |
@bplb 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 8 new commits 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 |
In further testing, with this change, CI test tiers 1-3 and 500 repeats of the subset of tests where the failure was observed passed on Windows. |
Just more context here. On Windows, when a file or socket handle is associated with an I/O completion port then the outcome may be handled on the initiating thread when the I/O op completes or fails immediately, or I/O completion status is queued. There are cases where it gets handled on the initiating thread but an I/O completion status is also queued. The buffer handled around this is tricky and it seems that since JDK 7, a substituted buffer can been returned to the TL buffer cache more than once. The changes in this PR will ensure can't handle. Future work could be done in this area to simplify several things but not now. |
/reviewers 2 |
@AlanBateman |
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 provided the change for this PR so I can't really be the reviewer too. So I've set reviewer to 2. @Michael-Mc-Mahon is going to help review too.
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.
Seems pretty straightforward. Looks fine.
/integrate |
Going to push as commit ea73e05.
Your commit was automatically rebased without conflicts. |
Thanks @AlanBateman for the patch and @Michael-Mc-Mahon for the approval! |
Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22554/head:pull/22554
$ git checkout pull/22554
Update a local copy of the PR:
$ git checkout pull/22554
$ git pull https://git.openjdk.org/jdk.git pull/22554/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22554
View PR using the GUI difftool:
$ git pr show -t 22554
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22554.diff
Using Webrev
Link to Webrev Comment