On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński <djelin...@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? Interesting, did not know that. Apart from the unknown performance characteristics, what about backward compatibility? Do we care for Windows older than 8? I share @dholmes-ora concern about scalibility. Your patch replaces the underlying mechanics for ObjectMonitor, right? We can have a lot of OMs, depending on how fast deflation is. Not many of them would be contended though. IIRC The Renaissance philosophers benchmark is a good example of mass synchronisation. If you run this with UseHeavyMonitors, it would be a good test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2178072230
