(S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line
doug.simon at oracle.com
Wed Nov 29 10:56:44 UTC 2017
> On 29 Nov 2017, at 10:05, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> This is redo of JDK-8190975  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  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.
More information about the core-libs-dev