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

[David Holmes]

Hi Jon,

On 25/07/2019 12:52 pm, Jonathan Gibbons wrote:
> 
> 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.

I agree that when the test configuration logic enables Graal it should 
add whatever flags are needed to enable Graal to work. However I don't 
know if that can be arbitrarily combined with test specific settings 
like --limit-modules. The module system folk would have to tell us how 
exactly --limit-modules works and whether there is another flag that 
would add the necessary access to the graal module without needing to 
augment the @modules section of the test.

David
-----

>  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
> 
>