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

[Vladimir Kozlov]

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.

Thanks,
Vladimir

> 
> -Alan.