RFR: 8294609: C2: Improve inlining of methods with unloaded signature classes [v2]

[Vladimir Ivanov]

On Thu, 29 Sep 2022 21:42:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> C2 bails out an inlining attempt when the callee method mentions an unloaded
>> class in its signature (either as an argument or return type).
>> 
>> The current check is too strict (and caused problems in the past [1]) since it
>> doesn't take into account whether the problematic class is loaded in the caller
>> context. It's safe to relax the original check in such a way because class
>> loader constratints ensure that both caller and callee agree on the signature
>> classes.
>> 
>> (I believe the aforementioned check [2] is redundant and can be removed even when
>> the class is not yet loaded, but I'll explore it separately.)
>> 
>> Testing: hs-tier1 - hs-tier4
>> 
>> [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2020-June/038604.html
>> [2] https://github.com/openjdk/jdk/blob/5f6ad926d7ea763bf61aa98c7be7087a7aa6089c/src/hotspot/share/opto/bytecodeInfo.cpp#L226
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Yes, it's the difference between `SystemDictionary::find_instance_klass()` the old code relied on (through `ResolvingSignatureStream::as_klass_if_loaded()` vs `SystemDictionary::find_constrained_instance_or_array_klass()` which `ciSignature` constructor uses through `ciEnv::get_klass_by_name_impl()`.

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

PR: https://git.openjdk.org/jdk/pull/10496