RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512
Pengfei Li (Arm Technology China)
Pengfei.Li at arm.com
Thu Jul 25 02:12:26 UTC 2019
> 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?
More information about the compiler-dev