fb64 commented on code in PR #1334: URL: https://github.com/apache/arrow-java/pull/1334#discussion_r4208285096
########## memory/memory-ffm/src/main/java/org/apache/arrow/memory/ffm/FfmMemoryAccessor.java: ########## @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.arrow.memory.ffm; + +import java.lang.foreign.MemorySegment; +import java.lang.foreign.ValueLayout; +import java.nio.ByteBuffer; +import org.apache.arrow.memory.util.MemoryUtilAccessor; + +/** + * {@link MemoryUtilAccessor} backed by {@code java.lang.foreign} ({@link MemorySegment} and the + * foreign {@link java.lang.foreign.Linker}). Does not use {@code sun.misc.Unsafe} or reflection + * into {@code java.nio} internals, so it requires neither {@code --add-opens} nor {@code + * sun.misc.Unsafe} availability. + * + * <p><b>Required JVM flag.</b> This accessor calls the restricted methods {@link + * MemorySegment#reinterpret(long)} and {@link java.lang.foreign.Linker#downcallHandle}, the latter + * for {@code malloc} and {@code free}. That is a real, current requirement, not a caveat that this + * module already handles for you: classpath (unnamed-module) consumers must pass {@code + * --enable-native-access=ALL-UNNAMED} and module-path consumers must pass {@code + * --enable-native-access=org.apache.arrow.memory.ffm} on the JVM command line. Without it the JVM + * prints a warning on every restricted call today, and a future JDK that enables restricted-method + * enforcement by default will turn that into a hard {@link IllegalCallerException}. The {@code + * Enable-Native-Access: ALL-UNNAMED} entry in this module's jar manifest does <em>not</em> cover + * this: the JVM only honours that attribute in the manifest of the jar it was launched with via + * {@code java -jar}, never for a jar that is merely a classpath dependency. + * + * <p>{@link #allocateMemory}/{@link #freeMemory} call {@code malloc}/{@code free} directly, like + * the {@code sun.misc.Unsafe}-backed accessor, so {@link #freeMemory} accepts any address returned + * by {@code malloc}. + */ +public final class FfmMemoryAccessor implements MemoryUtilAccessor { + + public static final MemoryUtilAccessor INSTANCE = new FfmMemoryAccessor(); + + private FfmMemoryAccessor() {} + + private static MemorySegment segment(long address, long byteSize) { Review Comment: Good question! I added accessor benchmarks to the gist, run with -prof gc: [https://gist.github.com/fb64/334d2eeb14e1e4c5adbff6e38e9f3b7e](https://gist.github.com/fb64/334d2eeb14e1e4c5adbff6e38e9f3b7e#accessor-reads-and-writes-does-escape-analysis-remove-the-segments) (section "Accessor reads and writes") Escape analysis does remove them: with default settings the FFM accessor allocates 0 B per value and matches Unsafe on reads and writes. As a control, with `-XX:-DoEscapeAnalysis` each access allocates 80 B (the two segments) and FFM gets 4 to 5x slower, so the benchmark does catch them when they exist. For `getByteBufferAddress`, escape analysis removes the allocations too, but copying into a direct `ByteBuffer` is still about 1.4 ns slower than Unsafe (5.6 ns vs 4.2 ns for 64 bytes). That cost is paid once per copy, whatever its size, not once per value. Instead of relying on C2 optimization, two improvements are possible: - Reads and writes: we can use a single global segment as a view over the whole native address space, created once, and access native addresses directly through it. I tried it CF [this gist section](https://gist.github.com/fb64/334d2eeb14e1e4c5adbff6e38e9f3b7e#one-shared-segment-no-escape-analysis-needed): with `-XX:-DoEscapeAnalysis`, reads and writes no longer allocate and match Unsafe and nothing changes with default settings. I can push it as a fixup. - `getByteBufferAddress`: we can drop the `duplicate()` with `MemorySegment.ofBuffer(buf).address() - buf.position()`, which returns the same address and cuts the lookup from 2.1 ns to 1.3 ns in a quick test. The segment created by ofBuffer can't be avoided with the public API, so this path would still rely on escape analysis. Can also push it as a fix-up I think it'd be a good idea. Let me know what you think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
