RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")
Dmitry Samersoff
dmitry.samersoff at oracle.com
Sat Feb 1 01:02:29 PST 2014
Looks good for me!
On 2014-02-01 06: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
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
More information about the hotspot-dev
mailing list