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

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?


More information about the compiler-dev mailing list