[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:
http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8191788
Thanks,
Vladimir
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 core-libs-dev
mailing list