Details
-
Enhancement
-
Resolution: Fixed
-
P3
-
8u72, 9
-
b26
-
generic
-
generic
Description
Today monitors are deflated by the VM thread in the beginning of every safepoint. In
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
Attachments
Issue Links
- relates to
-
JDK-8246477 add whitebox support for deflating idle monitors
-
- Resolved
-
-
JDK-8247280 more fencing needed in async deflation for non-TSO machines
-
- Resolved
-
-
JDK-8246476 remove AsyncDeflateIdleMonitors option and the safepoint based deflation mechanism
-
- Resolved
-
-
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-8246359 clarify confusing comment in ObjectMonitor::EnterI()'s race with async deflation
-
- Resolved
-
-
JDK-7021979 rapid sustained monitor circulation causes asymptotic increase in # of extant monitors
-
- Resolved
-
-
JDK-8305994 Guarantee eventual async monitor deflation
-
- Resolved
-
-
JDK-8264420 Allow MonitorUsedDeflationThreshold=0 for aggressive deflation of all eligible monitors
-
- Closed
-
-
JDK-8246676 monitor list lock operations need more fencing
-
- Resolved
-
-
JDK-8267842 SIGSEGV in get_current_contended_monitor
-
- Resolved
-
-
JDK-8246493 JDI stress/serial/mixed002 needs to use WhiteBox.deflateIdleMonitors support
-
- Resolved
-
-
JDK-8252126 'GVars.stw_random = os::random()' lost by JDK-8246476
-
- Resolved
-
-
JDK-8253183 Fragile memory barrier selection for some weak memory model platforms
-
- Resolved
-
-
JDK-8221616 gtest/GTestWrapper.java crashed due to SIGSEGV on Linux-X64
-
- Closed
-
-
JDK-8184751 Provide thread pool for parallel safepoint cleanup
-
- Resolved
-