[jdk17] RFR: 8268405: Several regressions 4-17% after CHA changes

[Vladimir Kozlov]

On Tue, 15 Jun 2021 15:25:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Recevier validation code in `Compile::optimize_inlining()` added by JDK-8267807 is way too strict. In particular, it rejects perfectly valid cases when unique concrete method comes from a superclass ( `receiver_type->klass() <: 
>  cha_monomorphic_target->holder()`).  
> 
> Instead of reworking the validation logic, I decided to completely get rid of it and follow John's @rose00 suggestion [1] to perform receiver checks at runtime when needed. As I described earlier [2], receiver checks should never fail unless there's a product bug lurking in the code. Debug builds will assert if it ever happens (controlled by `-XX:+-VerifyReceiverTypes`), but product builds will deoptimize at the call site instead.
> 
> (The fix depends on #55 to avoid assertion failures in `Parse::do_field_access()`.)
> 
> Testing:
> - [x] hs-tier1 - hs-tier6
> - [x] manual performance runs (dacapo-jython, in particular)  
> 
> [1] https://github.com/openjdk/jdk/pull/4212#discussion_r643467030
> [2] https://github.com/openjdk/jdk/pull/4212#discussion_r644377036

Just one comment.

src/hotspot/share/opto/doCall.cpp line 171:

> 169:         CallGenerator* cg = CallGenerator::for_inline(callee, expected_uses);
> 170:         if (cg != NULL && is_virtual_or_interface && !callee->is_static()) {
> 171:           CallGenerator* trap_cg = CallGenerator::for_uncommon_trap(callee,

Add comment here and in next changed code about why you want to deoptimize.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/60