[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor
From:       David Holmes <david.holmes () oracle ! com>
Date:       2019-08-29 11:53:20
Message-ID: 5eecfb2d-a1de-1b78-2215-5d2a21ee5c2c () oracle ! com
[Download RAW message or body]

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@oracle.com>
>> Sent: Donnerstag, 29. August 2019 01:20
>> To: Doerr, Martin <martin.doerr@sap.com>; serguei.spitsyn@oracle.com;
>> serviceability-dev <serviceability-dev@openjdk.java.net>;
>> jcbeyler@google.com; yasuenag@gmail.com; sgehwolf@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
>>>
[prev in list] [next in list] [prev in thread] [next in thread]