review for 7150390: JFR test crashed on assert(_jni_lock_count == count) failed: must be equal

[serguei.spitsyn at oracle.com]

Probably, you already do not need this... :)
It looks good (even better than previous one).

I also ran the nsk/jvmti and nsk/hprof tests with the JFR default 
recording enabled.
Fix (previous version) _vs_ no fix results are the same.
It is hard to compare the nsk/jdi as they are not very stable with the 
JFR yet.

Thanks,
Serguei

On 3/6/12 4:24 PM, Tom Rodriguez wrote:
> Thanks Coleen and Vladimir.  Yumin and David also reviewed this.
>
> tom
>
> On Mar 6, 2012, at 12:16 PM, Coleen Phillimore wrote:
>
>> This looks good.
>> Thanks,
>> Coleen
>>
>> On 3/6/2012 1:17 PM, Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/7150390
>>> 33 lines changed: 28 ins; 4 del; 1 mod; 7748 unchg
>>>
>>> 7150390: JFR test crashed on assert(_jni_lock_count == count) failed: must be equal
>>> Reviewed-by:
>>>
>>> Threads which have been suspended weren't being visited by the logic
>>> for maintaining the shared JNI critical count, resuling in incorrect
>>> values.  It's a very rare problem that could only occur as a result of
>>> JVMTI suspending a thread in the middle of a JNI critical operation
>>> which should in general be rare.  It showed up in the nightlies with
>>> regularity but I was unable to reproduce the original problem.  Adding
>>> the new visited flag identified the issue immediately.  Tested with
>>> tests from nightlies and the nsk JVMTI related tests.
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120306/6a0801eb/attachment.html