RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor

[David Holmes]

On 28/08/2019 10:57 pm, 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."

Yep it is allowed.

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

Doesn't seem to reproduce on Linux.

> At least, I can confirm that the following comment is true ��
> // FIXME: this is broken - raw_enter only accepts the VMThread

As I noted I had yet to reconcile the fact the outer raw monitor code 
seems to allow non-JavaThreads while the inner code only allows the 
VMThread! I'm quite surprised we have not encountered this bug before 
now - unless there is some really subtle code difference I'm missing here.

Anyway this is an aside to the question of interrupt semantics that 
needs to be addressed before this can proceed. :)

Thanks,
David

> Best regards,
> Martin
>