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/LayoutPath.java line 210: > 208: > 209: // (MS, long, long) if has strides, (MS, long) if no stride > 210: VarHandle handle = > Utils.makeRawSegmentViewVarHandle(rootLayout(), valueLayout, strides.length > == 0, offset); Super! To make the code clearer - I would assign `strides.length == 0` to a local variable, and then reuse that variable both here and in the branch below (to make it more explicit that the two things are connected -- e.g. no stride, no need for adaptation) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965239357
