RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

[Daniel D.Daugherty]

On Wed, 16 Sep 2020 00:07:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I've taken a first pass at creating a CSR:
>> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
>> https://bugs.openjdk.java.net/browse/JDK-8253121
>
> I've looked at the CSR and added myself as a reviewer.
> We had a slack chat with Dan, and I agree that with a weak handle it would be racy/unsafe for
> JVMTI_HEAP_REFERENCE_MONITOR calls back to be called. The ObjectMonitors do not pin objects anymore (there are no
> strong refs from them), so it has to be okay to skip reporting the JVMTI_HEAP_REFERENCE_MONITOR and and
> JVMTI_HEAP_ROOT_MONITOR (old Heap Walking API) reference types. The JVMTI does not need an update as other VM
> implementations can still report these reference types. Alan added a comment to the CSR saying that memory profiling
> tools that use the JVMTI functions (FollowReferences with jvmtiHeapReferenceCallback or IterateOverReachableObjects
> with jvmtiHeapRootCallback) to iterate over the heap should not have a compatibility impact as these reference types
> are just informational but adding a release note can be useful.

Slight clarification. Serguei and I were discussing whether we could continue
to make JVMTI_HEAP_REFERENCE_MONITOR call backs or emit
HPROF_GC_ROOT_MONITOR_USED entries in heap dump output as a
way to ease the transition phase of getting used to these things going
away. My answer was that we could do that but it would racy and unsafe
due to the ObjectMonitor's object being GC'ed.

It's also incorrect to make JVMTI_HEAP_REFERENCE_MONITOR call backs
or emit HPROF_GC_ROOT_MONITOR_USED entries in heap dump once
the ObjectMonitor's object ref becomes a weak handle. That weak handle
no longer prevents the associated object from being GC'ed so it is no
longer a strong root.

See Erik's comment above: https://github.com/openjdk/jdk/pull/135#discussion_r487291746

-------------

PR: https://git.openjdk.java.net/jdk/pull/135