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

Maurizio Cimadamore mcimadamore at openjdk.org
Thu Apr 10 15:55:37 UTC 2025


On Tue, 8 Apr 2025 12:24:41 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 which, if implemented, can take us three additional levels of inlining. I drew a line there. 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. 
>> 
>> Updating the `j.l.Object` constructor is crucial for the higher depths.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduce Object changes

src/java.base/share/classes/java/lang/Module.java line 180:

> 178:      * @jls 7.7.5 Unnamed Modules
> 179:      */
> 180:     @ForceInline

Doesn't the `ensureNativeAccess` code only depend on this one? Also, I'm having an hard time thinking that C2 can't inline this simple method? Isn't this an "accessor" ?

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 213:

> 211:      * a confined session and this method is called outside the owner thread.
> 212:      */
> 213:     @ForceInline

I presume this is added because it's called by the reinterpret implementation?

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 100:

> 98: 
> 99:     @Override
> 100:     @ForceInline

I'm not sure this is needed -- this is an "accessor" method - C2 typically inline those. But, do we depend on `maxAlignMask` for reinterpret?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037723817
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037726741
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037730266


More information about the hotspot-compiler-dev mailing list