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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Dec 13 08:16:39 UTC 2017

After several rounds of testing (which found different types of failures 
with Graal as JIT compiler) I decided to limit these changes for cases 
when --limit-modules is used:




On 11/29/17 3:19 PM, Vladimir Kozlov wrote:
> Yes, it was my limited understanding what --limit-modules is. We should 
> not add modules "under cover" when --limit-modules is used. User should 
> known all required modules *explicitly* to create correct image with 
> jlink based on result of runs with --limit-modules flag.
> Since it is limited set of tests which use --limit-modules (11 in 
> hotspot, 23 in jdk and few in closed) I will exclude these tests from 
> running with Graal as JIT by adding @require to them:
>   @requires !vm.graal.enabled
> We may revisit this later in a future when Graal become default JIT 
> compiler (it should be supported on platforms at that time).
> Thanks,
> Vladimir
> On 11/29/17 2:44 PM, mandy chung wrote:
>> Vladimir and I discussed this offline. java --limit-modules should 
>> have the same set of observable modules as running on an image that is 
>> created with jlink.  When running with -XX:+UseJVMCICompiler on a 
>> runtime image with just java.base, it will fail in the same way as 
>> running with java --limit-modules java.base -XX:+UseJVMCICompiler. 
>> These tests are written to run on a runtime image with java.base only 
>> should be updated to get it run with -XX:+UseJVMCICompiler.  I will 
>> take a look and see how we can refactor the tests to support such 
>> testing configuration.   In the meantime, Vladimir suggests to exclude 
>> these tests when running with -XX:+UseJVMCICompiler (specifying 
>> @requires).
>> Mandy

More information about the hotspot-dev mailing list