RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")

[serguei.spitsyn at oracle.com]

Thanks, Staffan!
Serguei

On 2/3/14 3:57 AM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 1 feb 2014, at 03:58, serguei.spitsyn at oracle.com wrote:
>
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-6471769
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/
>>
>> Summary:
>>
>>   There is a general issue in the suspend equivalent condition mechanism:
>>   Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results:
>>     - 1-st: true
>>     - 2-nd: false
>>
>>   This more generic suspend equivalent issue is covered by another bug:
>>     https://bugs.openjdk.java.net/browse/JDK-6280037
>>
>>   The bug to fix in this review is a specific manifestation of the 6280037
>>   in the JVMTI GetFrameCount() that has a big impact on the SQE nightly.
>>   It is on the Test Stabilization radar (as well as the 6280037).
>>   There are many tests intermittently failing because of this.
>>
>>   The webrev for review is a one-liner work around the 6280037 for the GetFrameCount().
>>
>>   The JVMTI GetFrameCount() spec tells:
>>     "If this function is called for a thread actively executing bytecodes (for example,
>>      not the current thread and not suspended), the information returned is transient."
>>
>>   So, it is Ok to call the GetFrameCount() for non-suspended target threads.
>>   To achieve safety, the frame count for non-suspended threads is calculated at a safepoint.
>>   It should be Ok and more safe to do the same for suspended threads as well.
>>   There is no big performance impact because it is already on a slow path.
>>   It is still important to avoid safepointing when the target thread is current.
>>
>>   The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label)
>>   as the most of the impacted tests are covered by the 6471769.
>>
>>
>> Testing:
>>   In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests
>>
>>
>> Thanks,
>> Serguei
>>