RFR: 8247281: migrate ObjectMonitor::_object to OopStorage

[Erik Österlund]

On Fri, 11 Sep 2020 20:31:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> 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.

> 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.

> 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.

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

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