RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512
Alan.Bateman at oracle.com
Thu Jul 25 09:03:45 UTC 2019
On 24/07/2019 21:12, Jonathan Gibbons wrote:
> I think this fix, and the one that preceded it, are both wrong, and
> that JDK-8227512 <https://bugs.openjdk.java.net/browse/JDK-8227512>
> should be backed out until we have a better solution.
> 1. I think it is a significant functional regression if a previously
> valid, unrelated test starts to fail when Graal is enabled. If this
> were a white-box test about testing JVMs, then changing the test code
> may be seen as reasonable. But the two tests in question are
> high-level tests of unrelated features. The test failures should be
> seen as underlying problems to be addressed, and not swept under the
> carpet with a workaround.
Most tests don't care if they are being tested with Graal or not. The
challenge for tests using --limit-modules is the set of observable
modules needs to expanded to include the Graal modules when testing
Graal. This can lead to two test descriptions or more invasive changes
when the test forks additional VMs and computes the value to specify to
--limit-modules in the test code.
In test/jdk, where we looked the other way when the TEST.ROOT changes
and VMProps helper were added, it means we can add `@requires
!vm.graal.enabled` to the tests using --limit-modules so they are
skipped when testing Graal. This avoids duplicate test descriptions and
changing test code and seems the least invasive approach. To do the same
for the javac tests in test/langtools would mean bringing in the
TEST.ROOT changes to run VMProps. If that isn't going to happen then it
might mean a Graal specific exclude list (like
test/jdk/ProblemList-graal.txt). I assume any other solutions would
starting a new discussion on how to test with Graal enabled.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev