JDK-8253121 : migrate ObjectMonitor::_object to OopStorage
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 16
  • Submitted: 2020-09-14
  • Updated: 2020-09-29
  • Resolved: 2020-09-21
Related Reports
CSR :  
JDK-8247281 - migrate ObjectMonitor::_object to OopStorage
Description
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.
Comments
I agree a release note is warranted here; moving to Approved.
21-09-2020
This CSR request is ready to move to Finalized. Please add a "release note" subtask to the main CR. Thanks.
16-09-2020
Thanks for chiming in, Alan! I was wondering how the reference types JVMTI_HEAP_REFERENCE_MONITOR and JVMTI_HEAP_ROOT_MONITOR (old Heap Walking API, also impacted) can be used by the memory profiling tools. And yes, the JVMTI does not need any changes as other implementations may have these reference kinds still reported. I've added myself as a reviewer.
15-09-2020
[~dholmes] - Please let [~eosterlund] know when you think this CSR is ready for the next step and what that next step should be in order to get this approved in a timely fashion.
15-09-2020
HPROF_GC_ROOT_MONITOR_USED just identifies a root type in a HPROF heap dump (so JDK-specific). Unlikely to have any real impact on tools that read heap dumps but it may lead to questions from developers that are using these tools. So I think a release note that documents the change would be useful. JVMTI agents used for memory profiling may be using the functions that iterate over the heap. I can't imagine any compatibility impact as the heap reference types are just informational. A release note may head off questions from the maintainers of these tools, or from users of these tools.
15-09-2020
The CSR needs to be edited and the "Compatibility Risk Description" section completed.
15-09-2020
I applied some judicious editing. I'm unclear how `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` may be used by application code. It may be these are purely informative descriptors that will simply now not been seen. I'm hoping the serviceabililty folk (paging [~sspitsyn]) will be able to clarify this aspect.
15-09-2020
Thanks for chiming in [~alanb]. Adding a release note makes sense to me too.
15-09-2020