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

mandy chung mandy.chung at oracle.com
Wed Nov 29 16:15:18 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.
I agree that augmenting --limit-modules doesn't seem the right solution 

Would @modules jdk.internal.vm.compiler be a temporary workaround so 
that this test will not run on SPARC where the module is not present?


More information about the core-libs-dev mailing list