On Wed, 19 Jun 2024 11:40:16 GMT, Daniel Jeliński <djelin...@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
