RFR: 8348556: Inlining fails earlier for MemorySegment::reinterpret [v5]

[Per Minborg]

On Thu, 6 Feb 2025 15:35:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more @ForceInline and a benchmark

src/java.base/share/classes/java/lang/Object.java line 44:

> 42:      * Constructs a new object.
> 43:      */
> 44:     @ForceInline

What is the implication of this?

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3570:

> 3568:      * @since 9
> 3569:      */
> 3570:     @ForceInline

These annotations are not totally out of the question as the corresponding methods (e.g. `public final long getLongUnaligned(Object o, long offset)` are `@IntrinsicCandidate` and will indeed be inlined because of that. So, this creates symmetry with respect to inlining.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1944931865
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1944936570