The com/sun/jdi/ForceEarlyReturnTest.java test fails transiently on libgraal when run with -Xcomp with:

[49294ms] failure: forceEarlyReturn() got unexpected exception: com.sun.jdi.InvalidTypeException
    at java.base/java.lang.Thread.getStackTrace(Thread.java:2421)
    at TestScaffold.failure(TestScaffold.java:493)
    at ForceEarlyReturnTest.runTests(ForceEarlyReturnTest.java:247)
    at TestScaffold.startTests(TestScaffold.java:470)
    at ForceEarlyReturnTest.main(ForceEarlyReturnTest.java:147)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
    at java.base/java.lang.Thread.run(Thread.java:1570)
java.lang.Exception: ForceEarlyReturnTest failed
    at ForceEarlyReturnTest.runTests(ForceEarlyReturnTest.java:259)
    at TestScaffold.startTests(TestScaffold.java:470)
    at ForceEarlyReturnTest.main(ForceEarlyReturnTest.java:147)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
    at java.base/java.lang.Thread.run(Thread.java:1570)


The problem is that the test does not take into account slower execution of the debuggee under -Xcomp.
This can be seen below where the stack trace shows that the debuggee has not yet entered the frame expected by the test. It's still waiting for blocking -Xcomp compilations.

Debuggee stack before forceEarlyReturn():
frame[0]: java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) (bci:0) (ClassLoader.java:1025)
frame[1]: java.security.SecureClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.CodeSource) (bci:12) (SecureClassLoader.java:150)
frame[2]: jdk.internal.loader.BuiltinClassLoader.defineClass(java.lang.String, jdk.internal.loader.Resource) (bci:117) (BuiltinClassLoader.java:862)
frame[3]: jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(java.lang.String) (bci:37) (BuiltinClassLoader.java:760)
frame[4]: jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.lang.String, boolean) (bci:111) (BuiltinClassLoader.java:681)
frame[5]: jdk.internal.loader.BuiltinClassLoader.loadClass(java.lang.String, boolean) (bci:3) (BuiltinClassLoader.java:639)
frame[6]: jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.lang.String, boolean) (bci:36) (ClassLoaders.java:188)
frame[7]: java.lang.ClassLoader.loadClass(java.lang.String) (bci:3) (ClassLoader.java:526)
frame[8]: ForceEarlyReturnTestTarg.loopOrSleep() (bci:0) (ForceEarlyReturnTest.java:76)
frame[9]: ForceEarlyReturnTestTarg.main(java.lang.String[]) (bci:69) (ForceEarlyReturnTest.java:105)

Possible fixes would include:
* Disable the test under -Xcomp
* Increase the time the main thread waits for the debuggee thread to reached the expected state. For example, it could be adjusted by JTREG_TIMEOUT_FACTOR (which is typically increased when running test with -Xcomp).