Hi David, 2019年8月29日(木) 8:30 David Holmes <[email protected]>:
> 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. > Sounds good. > > > 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? > I think the interruption for raw monitor can be option, and behavioral change does not give huge impact for JVMTI native agent developers. I have not used raw monitor with Thread::interrupt because raw monitor API is C/C++. So they are closed in JVMTI agent code in my experience. I used raw monitor in HeapStats [1] prototype in the past. It is for kicking callback functions of GarbageCollectionStart/Finish like a semaphore. So I do not need interruption for it. Especially in JVMTI event callbacks, raw monitor(s) do not need to expose to Java layer. Thanks, Yasumasa [1] https://icedtea.classpath.org/wiki/HeapStats 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 > >> >
