On Wed, 19 Jun 2024 16:50:22 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? > > Daniel Jeliński has updated the pull request incrementally with one > additional commit since the last revision: > > Update comment right. But the monitor lock is not fair, so between the time when the thread is unparked and the time when the thread actually acquires the lock, the lock can be acquired multiple times by other threads. As an experiment, I added code to print some debug output right after [the wait](https://github.com/openjdk/jdk/blob/f23295ec1dde58d239a2625c9b1645534a2bb625/test/langtools/jdk/jshell/UITesting.java#L182). Without this PR, the debug output appeared relatively infrequently. With this PR, JTREG reported output overflow, and the debug output was printed after every other character. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2191614094
