[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
here.
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?
Mandy
More information about the core-libs-dev
mailing list