On Wed, 19 Jun 2024 13:59:23 GMT, Viktor Klang <vkl...@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
