RFR: 8345826: Do not automatically resolve jdk.internal.vm.ci when libgraal is used

[Doug Simon]

On Fri, 16 May 2025 08:59:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> the set of modules in the training run is the same as the production run
>> 
>> I don't think that's true. That is, I don't think +EnableJVMCI is used in the training run is it @iklam ?
>> 
>>> Is it really terrible to disable the AOTClassLinking optimizations in that scenario?
>> 
>> Depends if you care as much about VM startup when using libgraal as when using C2. Is there a reason why only one of these should have AOTClassLinking startup benefits?
>> 
>> There's also the issue of all the AOTClassLinking tests having to be disabled/ignored/problem listed in the libgraal mach5 tiers. This is what initially motivated @iklam and I to come up with this solution.
>
>> Depends if you care as much about VM startup when using libgraal as when using C2. Is there a reason why only one of these should have AOTClassLinking startup benefits?
> 
> I should have been clearer, my question/comment was about the no-libgraal case, not the libgraal case. With the proposed change, I think you are looking to print an error. I'm wondering why it can't continue to add jdk.internal.vm.ci to the set of root modules.

Ok, that's a good suggestion. I'll explore further.

And I now understand your first comment about "+EnableJVMCI and libgraal is all good" is in the context of having applied this PR. In that context, the set of modules in the training run is indeed the same as the production run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25240#discussion_r2092699986