RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count

[serguei.spitsyn at oracle.com]

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/hotspot-runtime-dev/attachments/20140310/0d663144/attachment.html>