RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Mon Mar 10 07:00:43 UTC 2014
Hi Axel,
The webrev link does not work now.
I'll check it again tomorrow.
Thanks,
Serguei
On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote:
> Hi Axel,
>
> Thank you for fixing this issue.
> I'm reviewing it.
> It looks good in general, but a little bit more time is needed to look
> at the tests.
>
> Do you need a sponsor for pushing?
>
> Thanks,
> Serguei
>
>
> On 3/6/14 12:08 AM, Siebenborn, Axel wrote:
>>
>> Hi all,
>>
>> could I have a review for the following change?
>>
>> The recursive lock count for an object is not correct, in cases,
>> where a monitor is inflated after recursive lightweight locks. In
>> this case, the recursion count is taken from the heavyweight monitor,
>> represented by the class ObjectMonitor. ObjectMonitor::_recursions is
>> the number of times ObjectMonitor::enter() was called to acquire the
>> lock minus 1. This counter does not include the recursions of
>> lightweight locks, that happen before inflating the monitor and is
>> not equal to the recursion count from a Java source level point of view.
>>
>> I added a test to the webrev to reproduce the problem.
>>
>> The suggested fix is to call count_locked_objects, even if there's a
>> heavyweight monitor and get the recursion count by iterating the vframes.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8036666
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/
>> <http://cr.openjdk.java.net/%7Easiebenborn/8036666/webrev/>
>>
>> Thanks,
>>
>> Axel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140310/0d663144/attachment.html>
More information about the serviceability-dev
mailing list