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 >
