JDK-8249638 : Re-instate idle monitor deflation as part of System.gc()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2020-07-16
  • Updated: 2021-06-24
  • Resolved: 2021-06-24
Related Reports
Relates :  
JDK-8246477 - add whitebox support for deflating idle monitors
Description
All in-use monitors maintain a strong reference to their associated object and so will keep it live, even if the monitor reference is the only reference to that object. With asynchronous monitor deflation this can cause a surprise when code uses System.gc() to reclaim memory, but because monitors have not yet been deflated the memory is not actually reclaimed. Prior to JDK-8246477 there was a special hook in JVM_GC to trigger safepoint based deflation before the actual GC. That safepoint-based mechanism has been removed but was replaced with ObjectSynchronizer::request_deflate_idle_monitors(). We should call that in JVM_GC, and in all equivalent APIs (e.g. WhiteBox WB_FullGC).
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
24-06-2021
The following bug was used to change the ObjectMonitor::_object field into a weak reference: JDK-8247281 migrate ObjectMonitor::_object to OopStorage That change was integrated in jdk-16+17. So now an ObjectMonitor no longer contains a strong reference and should not pin an object in memory. There might still be other reasons to restore idle monitor deflation as part of a System.gc() call, but we have no observed pressing need at the moment. Changing this from a Bug to an RFE, lowering the priority to P5, and changing the "Fix Version" to "tbd".
13-11-2020
When Erik O's "weak monitor" work gets integrated this will no longer be an issue.
22-07-2020
ILW = MLM = P4
21-07-2020
This problem was observed during custom testing on a VM that forces inflation of monitors. Class unloading tests would fail because the System.gc() could not reclaim the class instances and so unload the class as expected. While System.gc() doesn't provide any firm guarantees about exactly what it does, we have introduced a change in behaviour going from synchronous monitor deflation, to async deflation, then to async without the JVM_GC hook. We should restore the previous behaviour.
16-07-2020