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

Reply via email to