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

[Alex Menkov]

Hi Daniil,

Looks good to me.

--alex

On 08/23/2018 20:29, Daniil Titov wrote:
> 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
> 
>