[10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line

[Jiangli Zhou]

> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> 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:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw
> 
> 16 tests.
> 
>> 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:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26
> 
> 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.

I agree with Vladimir. Skipping these tests on SPARC is not applaudable in this case as they are not Graal specific tests.

Thanks,
Jiangli

> 
> Thanks,
> Vladimir
> 
>> -Alan.