You can use jdk.test.lib classes to simplify the things.
Something like
ProcessBuilder pb = new
ProcessBuilder(JDKToolFinder.getTestJDKTool("jshell"));
Process p = ProcessTools.startProcess("JShell", pb,
s -> { // warm-up predicate
return s.contains(">jshell");
});
--alex
On 09/18/2019 15:44, Chris Plummer wrote:
Is there an easy way of doing this? Currently the jshell process is just
spawned using Runtime.exec().
Chris
On 9/18/19 3:01 PM, Alex Menkov wrote:
Hi Chris,
Did you think about waiting for jshell prompt ("jshell>") before run
"jhsdb jmap" command instead of delay or re-tries?
--alex
On 09/18/2019 14:11, Chris Plummer wrote:
Hello,
Please review the following changes:
http://cr.openjdk.java.net/~cjplummer/8228625/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8228625
There are actually numerous ways that JShellHeapDumpTest.java fails.
One is a test bug, being addressed here, and the rest all seem to be
SA bugs. Those are now being covered by JDK-8230872. All the issues
seem to stem from the fact that the test spawns a jshell process, and
then immediately does a "jhsdb jmap" on the process before jshell has
fully started up.
The test bug happens when the jmap succeeds, but jshell has not yet
entered the main java thread. Thus the search for
"JShellToolProvider" in the output fails. It expects
"JShellToolProvider" to be in the output because it is part of a
method name in the main thread, and the test dump all the thread
stacks contained in the jmap generated hprof file. When the test
fails in this way, you can see the stack dump in the output, but the
main thread is missing.
There's a couple of ways to fix this. One is to just add a delay (10s
seems to be more than enough), and the other is to retry the "jhsdb
jmap" command until the stack contains the JShellToolProvider symbol.
I chose the later because doing a 10s delay masks the SA issues that
are now covered by JDK-8230872. In a way the 10s delay is a better
fix, because it makes this test pass every time, but I did not like
that it also hid real SA problems in JDK-8230872. My plan for now is
to do this retry fix, and then if there are too many failures due to
JDK-8230872, then also add a 10s delay, with the intention of
removing it once JDK-8230872 if fixed. From what I can see,
JDK-8230872 failures happen on about 1% of the runs.
I made a few of other changes. One was to no longer redirect stderr
from the jmap process as was done from the following:
processBuilder.redirectError(ProcessBuilder.Redirect.INHERIT);
This causes the output not to appear in the OutputAnalyzer output,
resulting in the following not working:
output.shouldNotContain("null");
Also I added code to dump the output of the jshell process so you can
see if the jshell prompt was ever generated.
thanks,
Chris
