Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8253121

migrate ObjectMonitor::_object to OopStorage

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 16
    • hotspot
    • None
    • behavioral
    • minimal
    • Hide
      The way in which this change could introduce compatibility risk, is if there are applications that rely on the monitors of Java objects being reported to have a specially annotated monitor root. Since only certain contended representations of object monitors are associated with an ObjectMonitor in the first place, such an application would have to ensure that the ObjectMonitor does get inflated for it to be reliably reported. Even then, the application would have to ensure that said ObjectMonitor stays in_use() until the reporting happens, otherwise the VM can and will deflate the monitor, in which case no ObjectMonitor root will be reported to the object. So building a reliance on this behaviour seems theoretically possible, yet highly unlikely. You would essentially have to know the exact monitor and how it is being used, to know if it would reliably be reported to have a root. And if you know it so intimately, it seems like you are rather unlikely to need these APIs to report the monitor object, because you would already have to know which one it is, if you truly relied on it being reliably reported. Therefore my assessment is that the risk is very low.
      Show
      The way in which this change could introduce compatibility risk, is if there are applications that rely on the monitors of Java objects being reported to have a specially annotated monitor root. Since only certain contended representations of object monitors are associated with an ObjectMonitor in the first place, such an application would have to ensure that the ObjectMonitor does get inflated for it to be reliably reported. Even then, the application would have to ensure that said ObjectMonitor stays in_use() until the reporting happens, otherwise the VM can and will deflate the monitor, in which case no ObjectMonitor root will be reported to the object. So building a reliance on this behaviour seems theoretically possible, yet highly unlikely. You would essentially have to know the exact monitor and how it is being used, to know if it would reliably be reported to have a root. And if you know it so intimately, it seems like you are rather unlikely to need these APIs to report the monitor object, because you would already have to know which one it is, if you truly relied on it being reliably reported. Therefore my assessment is that the risk is very low.
    • File or wire format, Other
    • Implementation

      Summary

      While migrating ObjectMonitor::_object to OopStorage, we are also changing it from an oop to a weak handle. This change will have visible effects on JVM/TI Heap Callback functions and the heap dump format.

      Problem

      As a weak handle, the reference in ObjectMonitor will no longer be considered a (strong) root so JVMTI_HEAP_REFERENCE_MONITOR references will no longer be enumerated by JVM/TI Heap Callback functions.

      In addition, HPROF_GC_ROOT_MONITOR_USED entries will no longer be emitted in heap dumps.

      Please note that the ObjectMonitor is an implementation detail that is only associated with an object in certain situations. Contended locking, Object.wait() and some hash code situations can cause an ObjectMonitor to be associated with an object. It is possible in the current VM for no ObjectMonitors to be in use at a given point in time which means that the JVM/TI Heap Callback function would have no JVMTI_HEAP_REFERENCE_MONITOR references to enumerate and a heap dump would contain no HPROF_GC_ROOT_MONITOR_USED entries.

      Solution

      There is no "solution" as such. The change in the implementation simply results in a change in the observable behaviour.

      Specification

      No specification changes are planned since other VM implementations may continue to implement the oop in an ObjectMonitor as a (strong) root.

            eosterlund Erik Österlund
            dcubed Daniel Daugherty
            Daniel Daugherty, Serguei Spitsyn
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: