Fix FFM plugin OOM: scope native allocations to per-call Arena.ofConfined()

[Copilot]

Pi4JNativeContext.ARENA was a static final Arena.ofAuto() field. Every MemorySegment allocated for errno capture and data buffers on each native call accumulated there indefinitely — the arena never became unreachable, so GC could never reclaim those segments. Profiler confirmed jdk.internal.foreign.SegmentFactories$1 growing from 97k instances (4.7 MB) → 7.4M instances (357 MB) over 750k I2C iterations.

Changes

• Pi4JNativeContext — Clarifies ARENA is reserved for long-lived library lookups only (e.g. SymbolLookup.libraryLookup in SMBusContext). Exposes CAPTURED_STATE_LAYOUT as public static final for use in per-call arenas. Marks allocateCapturedState() @Deprecated(since="4.1.0", forRemoval=true).

• IoctlNative, SMBusNative, FileDescriptorNative, PermissionNative, PollNative — All per-call allocations (errno capture, data buffers) now use Arena.ofConfined() in a try-with-resources block, so native memory is freed deterministically at the end of each call.

// Before — allocates into static arena, never freed
var capturedState = context.allocateCapturedState();
var callResult = (int) IoctlContext.IOCTL.invoke(capturedState, fd, command, data);

// After — memory freed when try block exits
try (var arena = Arena.ofConfined()) {
    var capturedState = arena.allocate(CAPTURED_STATE_LAYOUT);
    var callResult = (int) IoctlContext.IOCTL.invoke(capturedState, fd, command, data);
    processError(callResult, capturedState, "callByValue", fd, command, data);
    return callResult;
}

The context field is retained in each Native class solely to trigger *Context class loading (and thus static MethodHandle initialisation) at construction time, preserving existing error-reporting behaviour.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkstyle.org
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.25.1/x64/codeql/tools/linux64/java/bin/java /opt/hostedtoolcache/CodeQL/2.25.1/x64/codeql/tools/linux64/java/bin/java -jar /opt/hostedtoolcache/CodeQL/2.25.1/x64/codeql/xml/tools/xml-extractor.jar --fileList=/tmp/codeql-scratch-850ba6d10baafc1e/dbs/java/working/files-to-index16705773135012226395.list --sourceArchiveDir=/tmp/codeql-scratch-850ba6d10baafc1e/dbs/java/src --outputDir=/tmp/codeql-scratch-850ba6d10baafc1e/dbs/java/trap/java (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[eitch]

@copilot what are the performance implications with these changes?

[FDelporte]

@copilot what are the performance implications with these changes?

@copilot

[Copilot]

@copilot what are the performance implications with these changes?

The change is net-positive for performance. Here's the breakdown:

Overhead of Arena.ofConfined() per call:

• Creating a confined arena is a lightweight object allocation (a few fields, no synchronization needed). JIT quickly inlines and eliminates most of the allocation cost.
• At close/exit of the try block, all segments in that arena are freed in a single sweep — only 1–3 segments per call (captured-state + 1–2 data buffers), so that sweep is trivially fast.
• Arena.ofConfined() is actually the fastest arena type in the JDK because it requires no synchronization (confined to the creating thread). The old Arena.ofAuto() relies on GC reachability and weak references, which are comparatively slower.

Why performance improves overall:

• The old static arena accumulated millions of SegmentFactories$1 objects (the profiler screenshots show 97k → 1.27M → 7.4M instances). This caused GC to spend increasing time scanning and managing reachability for all those weakly-referenced segments — even though they could never actually be collected (the arena was statically reachable). With the fix, each call's segments are freed deterministically on exit, GC has far less to track, and pause times shrink.
• Reduced memory footprint means fewer page faults and better CPU cache utilization.

Relative cost:
A writeThenRead I2C transaction involves at least one ioctl system call, which takes on the order of tens–hundreds of microseconds of kernel time. Creating and closing a confined arena takes nanoseconds. The arena overhead is effectively in the noise.

In short: negligible extra cost per call, meaningful reduction in GC overhead as the program runs longer.

@copilot what are the performance implications with these changes?

@copilot

See my reply above to @eitch for the full analysis — in short: negligible per-call overhead (nanosecond arena creation vs. tens–hundreds of microseconds for the actual system call), and the change actually improves overall performance by eliminating the growing GC burden caused by millions of accumulated SegmentFactories$1 instances in the old static arena.

[eitch]

For me this makes sense. We need to test it, but otherwise i think this is the correct approach.

[FDelporte]

@taartspi are you able to test before we merge?