On Mon, 26 Oct 2026 13:06:49 GMT, Aleksey Shipilev <[email protected]> wrote:
>> Our ongoing audit flags that newly added code (and recently modified by >> [JDK-8394802](https://bugs.openjdk.org/browse/JDK-8394802)) in Unsafe lacks >> @ForceInline, like some of their siblings do. It is both a code discipline >> issue, and potential performance roadbump if we somehow decide not to inline >> through these methods. >> >> I marked methods that AFAICS end up calling `@IntrinsicCandidate`, so >> forcing inlining for them pays off when we reach the intrinsic. >> >> Additional testing: >> - [x] Eyeballing Valhalla additions to Unsafe, no other hits >> - [x] Linux x86_64 server fastdebug, `java/lang/invoke compiler/unsafe` >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Aleksey Shipilev has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Merge branch 'master' into JDK-8395827-unsafe-forceinline > - A few more paths > - Merge branch 'master' into JDK-8395827-unsafe-forceinline > - Fix I think these `@ForceInline` are definitely necessary for `Object[]` argument methods (including `isFlatPayloadBinary` used by polymorphic array checks and `getFieldMap` used in acmp) and the memory operation primitives. What prompted you to inclue `arrayIndexScale` `arrayBaseOffset` that take array classes? They are just single-shot costs. If the goal is to make sure the whole VH routine gets inlined, we might need to ensure `VarHandles.checkAtomicFlatArray` gets inlined too and you can add even more annotations. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/33564#pullrequestreview-5671362943
