On Mon, 14 Sep 2020 17:10:39 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
>> I don't see anything in the HPROF format description that claims this is a >> strong root. At a minimum this seems to be a >> behavioural change that would warrant a CSR request. This also seems to be >> something that the serviceability folk >> should be made aware of and have a chance to comment on. > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/135
