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

[Dean Long]

On Thu, 29 Sep 2022 18:42:49 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

So the old code uses the caller's view of the signature and the new code uses the callee's view?  But where do we check that the two views are compatible?  If that's handled by loader constraints, where do we do that, in the verifier or in the interpreter and compilers?  It seems like we would need to do an implicit checkcast/instanceof for each inlined argument. 

Does the new test demonstrate failed loader constaints?

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

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