On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <[email protected]> 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
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review remarks, dates, some more simplifications
src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:
> 118: * with a {@link ValueLayout#varHandle()} call is cached inside a
> stable field of the value layout implementation.
> 119: * This optimizes common code idioms like {@code
> JAVA_INT.varHandle().getInt(...)}. A second layer of caching
> 120: * is then provided by this method, so different value layouts with
> same effects can reuse var handle instances.
I believe this comment is now out of sync? (It talks about two levels of
caching --- but there's only one now)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966264372
