RFR: 8345181: (ch) Windows asynchronous channels may return temporary direct buffers to the buffer cache twice (win)

[Alan Bateman]

On Wed, 4 Dec 2024 18:36:40 GMT, Brian Burkhalter <bpb 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.

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.

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.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22554#pullrequestreview-2479791325
PR Comment: https://git.openjdk.org/jdk/pull/22554#issuecomment-2518448817