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

[Jonathan Gibbons]

On 07/24/2019 09:40 AM, Jonathan Gibbons wrote:
>
> On 7/24/19 3:31 AM, Alan Bateman wrote:
>> On 24/07/2019 10:44, Langer, Christoph wrote:
>>> Hi Alan, Aleksey,
>>>
>>> thanks for the reviews.
>>>
>>> Here is an update which incorporates all suggestions: 
>>> http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/
>>>
>> This looks okay to me but probably best to have someone on 
>> compiler-dev okay to change too as that is where the javac tests are 
>> maintained. There is an argument that it would be simpler to just 
>> have these tests be skipped when testing with Graal.
>>
>> -Alan
>
>
> This seems wrong/misguided/over the top.
>
> On the one hand, javac is a relatively simple Java program that should 
> not need to depend on VM internals like this. Conversely, if a Java 
> program does need to depend on VM "internals" like this, perhaps they 
> should be exposed more publicly and not be "internal".
>
> -- Jon
>


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.

2. Even detecting whether or not Graal is enabled requires access to 
internal API, mediated through VMProps.java in the jtreg extraPropDefns 
mechanism, which calls down onto 
`sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to 
swallow #1 and have clients change their code when Graal is enabled, 
telling them how to detect if Graal is enabled is pretty dire.

-- Jon