Please review the change that fixes 4 JVMTI tests when running with Graal. One of the checks these tests perform compares the number of frames in the thread's stack returned by JVMTI GetFrameCount() with the number of frames entries returned by JVMTI GetStackTrace(). The thread to be tested executes arithmetic operations in the loop so the consequent calls of GetFrameCount() or/and GetStackTrace() should return the stack trace of the same depth.
However, with Graal on, additional "adjustCompilationLevel" frames could appear on the stack trace, e.g.: adjustCompilationLevel:166, HotSpotGraalCompilerFactory (org.graalvm.compiler.hotspot) adjustCompilationLevel:504, HotSpotJVMCIRuntime (jdk.vm.ci.hotspot) testedMethod:56, Test$Runner run:67, Test$Runner that results in the stack depth reported by the first invocation of GetFrameCount() or GetStackTrace() might differ from the stack depth reported by the consequent calls of the same methods. The fix modifies the tests to ensure the check that GetFrameCount () and GetStackTrace() report the same stack depth is performed only if the thread is suspended. For two tests (vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/TestDescription.java and vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/TestDescription.java) such check for suspended threads already exists so in these tests the problematic check was not modified by just removed. Issue: https://bugs.openjdk.java.net/browse/JDK-8209585 Webrev: http://cr.openjdk.java.net/~dtitov/8209585/webrev.01 Thanks, Daniil
