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

[Jonathan Gibbons]

On 7/24/19 7:12 PM, Pengfei Li (Arm Technology China) wrote:
> Hi Jonathan,
>
>> 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.
> Thanks for comments. But from your point, I don't see any better solution before Graal is moved out from the jdk.internal.* modules.
>
> Is it ok to problem-list these two cases? There's no ProblemList-graal.txt in langtools. Does the ProblemList-graal mechanism access VM internals as well?
>
> --
> Thanks,
> Pengfei
>

It would be OK to ProblemList these tests. I can't speak to how 
ProblemList-graal.txt works, but I'm guessing it uses Makefile magic and 
does not depend on any special jtreg or VM technology. If you can create 
the problemlist file in test/langtools, with no other changes to 
test/langtools, that would be a preferable solution to the changeset 
that is being proposed.

I'm not sure what you mean by "any better solution before Graal is moved 
out from the jdk.internal.* modules." It seems to me the problem is a 
missing module dependency and not by any side effect of being an 
"internal module".

I'm not familiar with anything beyond the superficial details of how 
Graal works in OpenJDK, but it seems to be the problem starts when the 
special -XX options are provided on the command line .... those switches 
seem to implicitly change the need for the extra module to be present, 
thus causing existing, working code to fail. In other words, the 
switches are not enough when a VM with limited modules is used. From an 
oustsider "layman" position, maybe the code underlying those switches 
should ensure that the module is made available, even in the face of a 
--limit-modules option.  One step short of that would be to detect the 
module is not available and to give a friendly helpful message instead 
of a crash and stack trace.  (And, again, I'm not an expert in this 
area, so apologies if this has been asked/discussed/answered elsewhere.)

-- Jon