RFR: 8345181: (ch) Windows asynchronous channels may return temporary direct buffers to the buffer cache twice (win)
Brian Burkhalter
bpb at openjdk.org
Wed Dec 4 21:02:47 UTC 2024
On Wed, 4 Dec 2024 20:02:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> 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.
>
> 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.
Thanks @AlanBateman for the patch and @Michael-Mc-Mahon for the approval!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22554#issuecomment-2518548396
More information about the nio-dev
mailing list