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

[Daniel Jeliński]

On Wed, 19 Jun 2024 13:59:23 GMT, Viktor Klang <vklang 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?
>
> src/hotspot/os/windows/os_windows.cpp line 5565:
> 
>> 5563:       prd = MAXTIMEOUT;
>> 5564:     }
>> 5565:     HighResolutionInterval *phri = nullptr;
> 
> @djelinski Is this even used?

yeah, it's the C++ construction where the constructor and the destructor have side effects. It increases the system timer resolution, unless `ForceTimeHighResolution` is set. `ForceTimeHighResolution`, contrary to its name and help text, forces [low timer resolution](https://bugs.openjdk.org/browse/JDK-6435126). Sigh.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19778#discussion_r1646283869