On 8/15/18 6:42 PM, Alex Menkov wrote:
Hi all,
please review a fix for
https://bugs.openjdk.java.net/browse/JDK-8209517
webrev:
http://cr.openjdk.java.net/~amenkov/sh2java/step1_regression/webrev/
test/jdk/com/sun/jdi/BreakpointWithFullGC.java
No comments.
test/jdk/com/sun/jdi/lib/jdb/Jdb.java
L101: 30, TimeUnit.SECONDS);
I'm assuming this is a 30 second timeout for getting the
initial "Listening for transport..." message. Keep in mind
that this may need to scale with timeoutFactor. I have seen
runs with -Xcomp take several minutes here...
L168: waitFor(10, TimeUnit.SECONDS);
L178: debuggee.waitFor(10, TimeUnit.SECONDS);
10 seconds may not be enough on a loaded machine with
lots of parallel processes. Keep in mind that this
may need to scale with timeoutFactor.
test/jdk/com/sun/jdi/lib/jdb/JdbCommand.java
No comments.
test/jdk/com/sun/jdi/lib/jdb/JdbTest.java
No comments.
Looks good to me. Is BreakpointWithFullGC.java the only test
that uses the com/sun/jdi/lib/jdb/*.java library code? That
would surprise me, but I haven't been in this test code for
a very long time.
Thumbs up!
Dan
Cause of the BreakpointWithFullGC failures is a mess of jdb and
debuggee outputs (the test runs debuggee by using CommandLineLaunch
connector, so jdb redirects debuggee stdout to its own stdout).
To solve it test framework was updated to launch debuggee first
(redirecting its output) and then connecting jdb to existing process.
The approach allow to drop "simple prompt" logic (jdb mode when
debugee is not yet running).
Mach5 passed 400 runs ("4 std platforms" x "--test-repeat 100")
without any issues.
--alex
