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