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.spit...@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
