(S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line
vladimir.kozlov at oracle.com
Wed Nov 29 17:27:29 UTC 2017
On 11/29/17 4:37 AM, Alan Bateman wrote:
> On 29/11/2017 11:26, David Holmes wrote:
>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting
>> --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using
>> JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do
>> --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set.
>> But the end result would seem the same.
> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and
> find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In
> the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when
> creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules.
There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open:
> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261.
I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will
require to add all Graal's "required" modules too:
If it acceptable I can do that instead.
But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal.
More information about the core-libs-dev