RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal

[Langer, Christoph]

Hi,

we observe this issue on some of our platforms (ppc64, ppc64le) where graal/jdk.internal.vm.compiler is not available. So a good fix would either be to have `@requires !vm.graal.enabled` or, if jtreg supports it, we'd need two sets of @modules directives and VM Options (--limit-modules) to cover both cases, with or without aot. Does anybody know if this is possible?

Thanks
Christoph

> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Pengfei Li (Arm Technology China)
> Sent: Donnerstag, 18. Juli 2019 08:52
> To: Alan Bateman <Alan.Bateman at oracle.com>
> Cc: nd <nd at arm.com>; compiler-dev at openjdk.java.net; hotspot-
> dev at openjdk.java.net
> Subject: RE: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with
> Graal
> 
> Hi Alan,
> 
> > I see this has been pushed but it looks like it is missing `@modules
> > jdk.internal.vm.compiler` as the test now requires this module to be in the
> > run-time image under test. As the test is not interesting when testing with
> the
> > Graal compiler then maybe an alternative is to add
> > `@requires !vm.graal.enabled` so that the test is not selected when
> > exercising Graal - we've done this in a few other tests that run with `--limit-
> > modules`.
> 
> Thanks for reply. I've used this alternative approach before when I tried to
> clean up other false failures in Graal jtreg (see
> http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae). This time I choose to
> add the missing module because I thought the javac test would be
> interesting when Graal is used since javac is also written in Java. This change
> is already pushed, but it's fine to me if you would like to submit another
> patch to disable this two cases with Graal.
> 
> --
> Thanks,
> Pengfei