2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits))
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Feb 4 07:48:10 PST 2014
On 2/4/14 4:13 AM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> Open webrev:
No comments beyond David's tweak to the comment.
For future work...
Looks like these VM ops also need the liveness check on the
JvmtiEnv::GetStackTrace() looks like it has the same
> This is the second round of review for this issue.
> But it was decided that the JDK-8032223 must be used to cover it
> instead of the JDK-6471769.
> The 8032223 was initially closed as a dup of 6471769 but it has been
> re-open now.
> 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 suspend equivalent issue is covered by another bug:
> The bug to fix in this review is a specific manifestation of the
> in the JVMTI GetFrameCount() that has a major impact on the SQE
> It is on the Test Stabilization radar as well as the 6280037.
> There are many tests intermittently failing because of this.
> I've also decided to fix the same issue in the JVMTI
> GetFrameLocation() as well.
> 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 the non-suspended
> target thread.
> 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 should be 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 must be covered by the 8032223.
> In progress:
> - nsk.jvmti, nsk.jdi, nsk.jdwp
> - JTreg com/sun/jdi
More information about the hotspot-dev