Ioi,
Your comments are noted, but there is a better update I have had in mind
for a while, which I have avoided until now, while we stabilize JDK 9,
and for fear of disrupting test runs. This fix will isolate the compiled
"class path" classes for each test, in the same way that updates for
modules have isolated the "module path" classes for each test.
-- Jon
On 6/5/17 6:25 PM, Ioi Lam wrote:
From the mails I can appreciate people have wildly different opinion
about the virtue of @build :-)
But regardless of your opinion on @build, I think the issue I
identified in CODETOOLS-7901986 [1] is definitely a bug -- the bug is
when a library is compiled, it incorrectly depends on classes that
come from the test case.
Arguably, fixing this bug would make people less afraid of using
@build. The HotSpot decided to stop using @build because unless ever
single test is perfectly following the @build rules, there's a chance
of random NoClassDefFoundError caused by incorrectly compiled
libraries due to CODETOOLS-7901986.
So please fix this bug. If we want to enforce the rules for @build,
that should be done separately. The enforcement should not be done via
undiagnosable random failures.
Thanks
- Ioi
[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
On 6/5/17 3:16 PM, Jonathan Gibbons wrote:
Igor, Ioi,
I have read Ioi's mail and the supposed bug fix.
While the fix may hide the problem, the root cause is still that
tests are not providing accurate @build directives, and are relying
on implicit compilation to compile the files. This is not the way
that jtreg is intended to be used, and the fix merely helps hide the
problem, albeit in a relatively elegant way.
-- Jon
On 05/31/2017 07:18 AM, Igor Ignatyev wrote:
Hi Alan,
we believe it's a jtreg bug. we have seen similar intermittent
failures in hotspot testing[1], Ioi(cc'ed) did a really great job
analyzing the root cause[2], in to words jtreg puts a part of
testlibrary to one path and another part to a different path. [3] is
his suggested fix for jtreg.
-- Igor
[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
[2]
https://bugs.openjdk.java.net/secure/attachment/70197/jtreg_random_class_not_found.txt
[3] http://cr.openjdk.java.net/~iklam/jtreg/7901986_split_library/
On May 31, 2017, at 1:38 AM, Alan Bateman <[email protected]>
wrote:
On 31/05/2017 09:05, Felix Yang wrote:
Hi Alan
even with explicit compilation, I also observed failures. I'm
curious what is the best practice here. IMO, there could be a
potential jtreg bug.
One of the tests listed in JDK-8181299 is
java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the
test description has:
@build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools
Test
but the test fails intermittently with:
java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
at jdk.test.lib.process.OutputAnalyzer.<init>(OutputAnalyzer.java:47)
at
jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
at
jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
at
jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
at TestDriver.main(TestDriver.java:61)
I assume changing the @build to jdk.test.lib.process.* will fix
this, assuming all the classes needed for ProcessTools are in this
package.
As to why it's intermittent then I think it's a side effect of test
library classes being compiled by one test and then re-used by a
test that runs sometime later in the same VM. Combine that with
implicit compilation, varied @build usages, and concurrently should
explain why it's intermittent. I see you've cc'ed Jon Gibbons and
he is the best person to comment on this. Now seems a good time to
get to the bottom of these issues, esp. with Igor changing lots of
tests to drop the explicit compilation of test library classes.
-Alan
