On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <li...@openjdk.org> wrote:
> Simplify the layout access var handles to be direct in some common cases.
> Also made `VarHandle::isAccessModeSupported` report if an access mode is
> supported for a VH.
>
> Reduces the instructions to execute this code in a simple main by 47%:
>
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>
>
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always
> have large overhead
>
> Still need other measures to deal with common user patterns of
> `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very
> slow.
>
> Tests: 2 unrelated failures on tier 1-3
src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line
164:
> 162: @ForceInline
> 163: public final VarHandle varHandle() {
> 164: record VarHandleCache() implements
> Function<AbstractValueLayout<?>, VarHandle> {
Can this cache be removed? The var handles created here should be "direct" --
meaning that we don't expect LayoutPath to add any adaptations on top of what's
already done in the "raw" var handle returned by
`Utils:makeRawSegmentViewVarHandle`?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965294264
