RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor

[David Holmes]

Hi Yasumasa,

On 29/08/2019 12:14 am, Yasumasa Suenaga wrote:
> 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?

No. In the new code "_owner" is only an informational field used by the 
current thread to detect its own recursive lock usage. Actual ownership 
is determined by the successful lock or tryLock of the underlying 
PlatformMonitor.

However I had been thinking about memory ordering and there are missing 
membars. We have to do:

lock(); _owner=THREAD;
_owner=NULL; unlock();

in the order specified so I need to insert storestore barriers.

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

Yes. Though I'd still like to understand why we don't see the same 
assertion failure in existing code.

But moving on ... what are your thoughts on the interrupt semantics?

Thanks,
David


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