RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor
David Holmes
david.holmes at oracle.com
Thu Aug 29 11:53:20 UTC 2019
Hi Martin,
On 29/08/2019 9:06 pm, Doerr, Martin wrote:
> Hi David,
>
> shouldn't _recursions get set to 0 before unlocking in raw_wait?
Yes. And there's a missing assertion that _recursions==0 in quick-enter.
Thanks,
David
> 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
>>>
More information about the serviceability-dev
mailing list