RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used

[Thomas Stuefe]

On Wed, 19 Jun 2024 11:40:16 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

> As you found out already, the implementation is based on a hash table, so access will be slower with many threads waiting at the same time. The hash table is stored in user space (in PEB), and the implementation reportedly doesn't require any kernel resources.
> 
> I'm not sure what to do with the remaining reference to `WaitForSingleObject`; it explains why we decompose the timeout by pointing to `EventWait`, which no longer exists as far as I could tell. I'll search the history some more before I decide what to do with that comment.
> 
> I don't think we care about pre-Win8 OSes at this point. JDK-11 was the last version to support Windows 7, I guess we won't backport this change there.
> 
> The patch replaces the underlying mechanics of ObjectMonitor. The ParkEvent is only used when a thread is blocked on a monitor, so the number of concurrent waits will never be greater than the total number of running threads.
> 
> I'll check if I can run Renaissance philosophers. Could you explain how UseHeavyMonitors changes the benchmark?

With UseHeavyMonitors, even uncontended locks are inflated to OMs. Otherwise, we use stack locking resp. now lightweight locking. The benchmark itself generates a lot of locks IIRC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2178538329