RFR(XS): 8167001: [TESTBUG] java/lang/instrument/DaemonThread/TestDaemonThread.java fails when run by jprt
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Tue Oct 4 21:18:35 UTC 2016
Hi Chris,
It looks good to me.
But I have a question.
Would it also work if we add "othervm" to the test TestDaemonThread.java?
It seems other j.l.i tests are run in this mode.
Thanks,
Serguei
On 10/4/16 10:43, Chris Plummer wrote:
> Hello,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8167001
> http://cr.openjdk.java.net/~cjplummer/8167001/webrev.00/webrev.jdk/
>
> This fixes an issue with the classpath not being passed to the
> subprocess, resulting in the main class for the subprocess not being
> found. It only turns up when running the test with "agentvm", which is
> the default when running the test via test/Makefile (which is what
> jprt uses). "othervm" seems to be the default when running jtreg
> directly from the command line, so it doesn't see this problem.
>
> Although there are still ongoing discussion of jtreg classpath
> definition differences between "agentvm" mode and "othervm" mode,
> existing tests fix this issue by explicitly passing the classpath to
> the subprocess. This is usually done by passing "true" as the first
> argument to ProcessTools.createJavaProcessBuilder(), so I'd like to go
> with this fix for now. This is actually the default behavior for
> hotspot/test. For jdk/test the default is "false" so you need to
> explicitly pass "true".
>
> Tested by running with jprt under conditions where the test was
> previously failing. Also tested by running the test directory locally
> using jdk/Makefile (which previously was failing).
>
> thanks,
>
> Chris
More information about the jtreg-dev
mailing list