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 make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 45: > 43: $1_Type := $2 > 44: > 45: ifeq ($$($1_Type), Boolean) These changes in ScopedMemoryAccess are not strictly required -- but I imagine they simplify your implementation of the var handle impl methods. So, it's ok to leave them in. make/modules/java.base/gensrc/GensrcVarHandles.gmk line 171: > 169: # Param 1 - Variable declaration prefix > 170: # Param 2 - Type with first letter capitalized > 171: # TODO decide if CAS/Bitwise/AtomicAdd should be enabled for subints Exactly - let's keep this out for now (they seem to be currently enabled -- and I'd prefer to do that separately, after some discussion) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965204113 PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965202095