RFR: 8247281: migrate ObjectMonitor::_object to OopStorage

[Daniel D.Daugherty]

On Fri, 11 Sep 2020 21:08:59 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 3021:
>> 
>>> 3019:
>>> 3020:   // Inflated monitors
>>> 3021:   blk.set_kind(JVMTI_HEAP_REFERENCE_MONITOR);
>> 
>> So we don't have to provide the equivalent of JVMTI_HEAP_REFERENCE_MONITOR?
>
> The JVMTI roots are strong roots. This is no longer a strong root, so reporting them would be a bug after this change.

The function is VM_HeapWalkOperation::collect_simple_roots()
and we no longer have a root in the ObjectMonitor so my take is
no we don't. I believe @fisk concurs with that reasoning.

>> src/hotspot/share/runtime/objectMonitor.cpp line 268:
>> 
>>> 266:     return NULL;
>>> 267:   }
>>> 268:   return _object.resolve();
>> 
>> Why would _object be NULL?  It should be non-null after creation.  It might point to null but then _object.resolve()
>> would return NULL.  This NULL check doesn't make sense to me, same with the peek function below.
>
> Because before the TSM removal patch, the monitors are allocated in blocks. Then, the objects are not known when the
> monitors are allocated. The handles are instead lazily created... for now. With the next patch, that will probably
> change, if we agree to allocate ObjectMonitors one by one on inflation time. But that is one patch away.

Erik's part3 patch ensures that when the ObjectMonitor is allocated,
the weak handle is created and initialized to the oop at that point. Since
this is still the TSM version, the ObjectMonitor may not yet have a weak
handle allocated at the time that object() is called.

>> src/hotspot/share/services/heapDumper.cpp line 1395:
>> 
>>> 1393:   void do_oop(oop* obj_p) {
>>> 1394:     u4 size = 1 + sizeof(address);
>>> 1395:     writer()->start_sub_record(HPROF_GC_ROOT_MONITOR_USED, size);
>> 
>> I had a similar question to the jvmtiTagMap question above.  Are there tools that are going to miss seeing this tag in
>> the heap dump?  I hope these tags are implementation defined and we can just remove them.  Otherwise, should there be a
>> loop through the OM list to print out these tags for live object monitors?
>
> Same answer as above. No longer a strong root, so can't report it as such.

We no longer have a root in the ObjectMonitor so no we don't have
to dump these is my take. I believe @fisk concurs with that reasoning.

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

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