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

[Siebenborn, Axel]

Hi Sergui,
thanks for reviewing.
Yes, I need a sponsor.

Thanks,
Axel


From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com]
Sent: Freitag, 7. März 2014 10:32
To: Siebenborn, Axel; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count

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/20140307/22b6e1ff/attachment.html