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

[Vladimir Ivanov]

> 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

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/60/files
  - new: https://git.openjdk.java.net/jdk17/pull/60/files/dfe826fa..23ef487f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=60&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=60&range=00-01

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/60/head:pull/60

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