RFR: 8209585: [Graal] vmTestbase/nsk/jvmti/scenarios/sampling tests fail with "Too small stack of resumed thread"

Daniil Titov daniil.x.titov at oracle.com
Fri Aug 24 03:29:19 UTC 2018


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




More information about the serviceability-dev mailing list