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

[Igor Ignatyev]

Hi Pengfei, Jon,

ProblemList-graal.txt files don't use any magic at all, neither do they depend VMProps, special jtreg or VM technology. these are just extra problem list files, which you are supposed to add into your command lines whenever you are using Graal . the way we (Oracle) use them is by simply adding 'JTREG_EXTRA_PROBLEM_LISTS=ProblemList-graal.txt' (or 'JTREG=EXTRA_PROBLEM_LISTS=ProblemList-graal.txt') to our 'make test' commands, makefiles take care of checking if the file exists and adding an extra '-exclude:' to jtreg command line. in other words, you can create ProblemList-graal.txt in 'test/langtools/' directory and it will be used in the same way as ProblemList-graal.txt files from other test suites.

HTH,
-- Igor

> On Jul 24, 2019, at 7:52 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> 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.  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
> 
>