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

[Richard Reingruber]

On Fri, 31 Mar 2023 23:10:28 GMT, Dean Long <dlong at openjdk.org> wrote:

> 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.

The problem is present in HEAD. Modification of Metadata references would require fixup if not stored as an immediate operands in the instruction stream as on x86. But this was never implemented (`metadata_Relocation::pd_fix_value()` is empty) since Metadata objects don't move. So if the [target Method* is cleared from a static stub](https://github.com/openjdk/jdk/blob/ecec611af6c6314d7a834392f38468ad3f390e2d/src/hotspot/share/code/compiledMethod.cpp#L661-L665) readers will see this but executing threads would get the dangling pointer because the fixup wasn't done.

If holder of the target is stored in an oop slot associated with the optimized call then cleaning of static stubs can be removed because the holder will be kept alive if the caller is on stack. If it is not on stack and the holder is unloading then the caller will be unloading too.

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

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