Hi David, shouldn't _recursions get set to 0 before unlocking in raw_wait?
Best regards, Martin > -----Original Message----- > From: David Holmes <[email protected]> > Sent: Donnerstag, 29. August 2019 01:20 > To: Doerr, Martin <[email protected]>; [email protected]; > serviceability-dev <[email protected]>; > [email protected]; [email protected]; [email protected] > 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 > >
