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.


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>

More information about the hotspot-runtime-dev mailing list