On Fri, 21 Feb 2025 20:14:19 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
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review remarks, dates, some more simplifications
Marked as reviewed by mcimadamore (Reviewer).
src/java.base/share/classes/jdk/internal/foreign/Utils.java line 130:
> 128: */
> 129: public static VarHandle makeRawSegmentViewVarHandle(MemoryLayout
> enclosing, ValueLayout layout, boolean noStride, long offset) {
> 130: if (enclosing instanceof ValueLayout direct) {
For now the caching is ok. Moving forrward, I wonder if we shouldn't add more
reuse between field var handles in cases like these:
struct Point {
int x; int y;
}
struct Tuple {
int u; int v;
}
E.g. if I access the first field in these two structs, then the var handle will
be identical? In a way, we use the enclosing layout for two reasons:
* to determine the size `S` of the accessed memory region
* to determine the alignment `A` of the accessed memory region
So, if the static `offset`, accessed `layout`, `S` and `A` are the same for two
accesses, we should probably reuse the same var handle instance? E.g. whether
we access `x` in a `Point`, or `u` in a `Tuple` makes little difference.
-------------
PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2636794415
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1967472774
