RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512

[Alan Bateman]

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.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190725/0c492313/attachment.html>