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
