RFR: 8296440: Remove Method* handling from cleanup_inline_caches_impl [v5]

[Dean Long]

On Wed, 29 Mar 2023 19:54:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Check only in debug vm
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/ff368d50...7dd06446

BTW, I experimented with a growable nmethod oops table in JDK-8294002, but ran into problems for reasons I can't remember.  I think reserving a slot per call site would be the safest approach.  However I saw a potential problem with platforms like Aarch64 that appear to store the metadata in two places, the move instruction sequence itself and the relocation metadata slot.  If those two places aren't kept consistent then there could be a situation where the call site oop protects one of the values but not the other.

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

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1492710760