> On 29 Nov 2017, at 10:05, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 28/11/2017 23:51, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to >> tests which have --limit-modules option. Unfortunately tests start failing >> on SPARC where Graal (jdk.internal.vm.compiler) is not available. >> JDK-8191653 [2] reversed 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only >> when Graal is used: when it is explicitly specified with >> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. >> >> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS >> tests in test/runtime/appcds/jigsaw and also >> test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle Labs >> version of Graal). >> But it should be fine since it is only used with --limit-modules which is >> not used by Labs. > If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the > tests have `@requires jdk.internal.vm.compiler` and jtreg will skip the test > on that platform? > > Just asking as augmenting the value passed to --limit-modules is very > strange. It's normal for XX options to augment the set of modules that > resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for > example) but doing this for --limit-modules suggests the VM is doing > something to mask an issue with the way that the tests are run.
As much as I understand the issue, I agree. This seems like something that should be addressed in the test(s) instead of in the VM. -Doug
