RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads

[Chris Plummer]

On Fri, 4 Dec 2020 15:30:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused
> timeout failures when graal is enabled.
> 
> The fix is to avoid suspending all threads when a breakpoint is reached and then resume
> just the main thread again. This pattern was used in the test case
> EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal
> threads remained suspended and, running with -Xbatch, the main thread waited
> (with timeout) for completion of compile tasks.
> The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only
> to the main test thread and all explicit resume calls apply to all java threads.
> 
> Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is
> reduced from 30s to 10s.

test/jdk/com/sun/jdi/EATests.java line 1274:

> 1272:                 o = getLocalRef(env.targetMainThread.frame(0), XYVAL_NAME, "xy");
> 1273:             } catch (Exception e) {
> 1274:                 msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")");

Please move the increment of retryCount to before the msg() call for clarify.

test/jdk/com/sun/jdi/EATests.java line 1275:

> 1273:             } catch (Exception e) {
> 1274:                 msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")");
> 1275:                 env.vm().resume();

You are calling `VM.resume()` in a loop, yet you are suspending using `ThreadReference.suspend()`. Although the it looks like this will work, it seems that calling `ThreadReference.resume()` would be more appropriate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1625