Today monitors are deflated by the VM thread in the beginning of every safepoint. In JDK-7021979 it was observed that 250,000 monitors can easily take up to 8ms to process. The 250,000 monitors were created artificially using a small java program.
At Twitter we have seen programs with more than 600,000 monitors and 6500 threads. The ratio between threads and monitors allocated is less than 10% of the MAXPRIVATE (1024) private monitors per thread, suggesting these program do not suffer from the issue reported in JDK-7021979.
- blocks
-
JDK-8225631 Consider replacing muxAcquire/Release with PlatformMonitor
-
- In Progress
-
- relates to
-
JDK-7021979 rapid sustained monitor circulation causes asymptotic increase in # of extant monitors
-
- Open
-
-
JDK-8149442 MonitorInUseLists should be on by default, deflate idle monitors taking too long
-
- Resolved
-
-
JDK-8180175 ObjectSynchronizer only needs to iterate in-use monitors
-
- Resolved
-
-
JDK-8180932 Parallelize safepoint cleanup
-
- Resolved
-
-
JDK-8221616 gtest/GTestWrapper.java crashed due to SIGSEGV on Linux-X64
-
- Closed
-
-
JDK-8184751 Provide thread pool for parallel safepoint cleanup
-
- Resolved
-