RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

[Daniel Jeliński]

On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed, but they are recycled when a thread dies, so the number of live ParkEvent instances is proportional to the maximum number of threads that were live at any time.
>> 
>> On Windows, the ParkEvent object wraps a kernel Event object. Kernel objects are a limited and costly resource. In this PR, I replace the use of kernel events with user-space synchronization.
>> 
>> The new implementation uses WaitOnAddress and WakeByAddressSingle methods to implement synchronization. The methods are available since Windows 8. We only support Windows 10 and newer, so OS support should not be a problem.
>> 
>> WaitOnAddress was observed to return spuriously, so I added the necessary code to recalculate the timeout and continue waiting.
>> 
>> Tier1-5 tests passed. Performance tests were... inconclusive. For example, `ThreadOnSpinWaitProducerConsumer` reported 30% better results, while `LockUnlock.testContendedLock` results were 50% worse. 
>> 
>> Thoughts?
>
> Daniel Jeliński has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

The test uses 2 threads that are serialized - when one is working, the other one is blocked, and vice versa. The publisher thread is publishing characters one at a time, so it's doing the same amount of work on every test run. The subscriber thread is doing a large amount of work every time it gets the monitor, and the amount of work does not depend on the number of bytes published since the last time the subscriber thread was run.

With the original code, the publisher thread was getting the monitor ~100x more often than the subscriber thread; with the new code, the publisher thread gets the monitor 2x more often than the subscriber thread. In other words, the subscriber thread is running 50x more often than before, and does proportionally more work. This translates the running time increase.

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

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2255014057