RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor

[Doerr, Martin]

Hi David,

shouldn't _recursions get set to 0 before unlocking in raw_wait?

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Donnerstag, 29. August 2019 01:20
> To: Doerr, Martin <martin.doerr at sap.com>; serguei.spitsyn at oracle.com;
> serviceability-dev <serviceability-dev at openjdk.java.net>;
> jcbeyler at google.com; yasuenag at gmail.com; sgehwolf at redhat.com
> Subject: Re: RFC: 8229160: Reimplement JvmtiRawMonitor to use
> PlatformMonitor
> 
> 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
> >