RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor

[Yasumasa Suenaga]

Hi,

I guess this issue was occurred on ObjectFree JVMTI event.
It is registered in a04t001.cpp [1]. I think it might be called on GC worker because it relates to JvmtiExport::weak_oops_do().

In current code, JvmtiRawMonitor::_owner is handled with atomic operation.
However at JvmtiRawMonitor::quick_enter() in new webrev, it just referent normally.
Should it be handled atomically?


At least, I think this assert might be failed in current code because raw monitor might be handled on GC worker. So "FIXME" comment Martin found is valid...


Thanks,

Yasumasa


[1] hg.openjdk.java.net/jdk/jdk/file/4f38fcd65577/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp#l219


On 2019/08/28 21:57, Doerr, Martin wrote:
> Hi David,
> 
>> Now why would a GCTaskThread being executing code that accesses
>> JvmtiRawMonitors? Are we in some kind of event callback?
> I believe so. The test registers the following callbacks:
>      callbacks.GarbageCollectionStart = &GarbageCollectionStart;
>      callbacks.GarbageCollectionFinish = &GarbageCollectionFinish;
> And these callback functions use jvmti->RawMonitorEnter.
> 
> Note that the spec for "Raw Monitor Enter" allows this:
> "This function may be called from the callbacks to the Heap iteration functions, or from the event handlers for the GarbageCollectionStart, GarbageCollectionFinish, and ObjectFree events."
> 
>> Is there any more stack? What is that dll?
> The dll belongs to the test. I guess it was built without debug info so there's no native stack trace available.
> 
>> Can you tell me what test this was and how to reproduce?
> make run-test TEST="vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001"
> I haven't tried if it can be reproduced well. May be sporadic.
> 
> At least, I can confirm that the following comment is true ��
> // FIXME: this is broken - raw_enter only accepts the VMThread
> 
> Best regards,
> Martin
>