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 What I don't understand: Events are kernel events. We can release Events. WaitOnAddress builds up a kernel-side hash table, but is there a way to ever release these addresses and shrink the table, if you don't need the synchronization anymore? Can you ever release the underlying memory? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2179889219