RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor

[Yasumasa Suenaga]

Hi David,

2019年8月29日(木) 8:30 David Holmes <david.holmes at oracle.com>:

> 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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190829/0b3d5328/attachment.html>