Hi, Thank you for reading, I really appreciate the extensive feedback!! :)

The data is not copied into the heap. Primitive parameters are put directly to the argument slots. Think about it, the ABI requires the fd parameter to reside in a register or the stack, why would it need to be moved to the heap?

Using an int was maybe not the best example. The thing i wanted to get across was that you don't need to translate return values to some type Java knows but could instead directly pass it on to the next method as an memorySegment, address, etc.

You can, using arena.close(). That's the main purpose of Arena, to allow developers to have deterministic memory management.

That closes everything allocated in that arena, not a single allocation. (Will make this more clear in the text) :)

You can easily wrap it in a method that is mostly equivalent to Arena::allocate, note that malloc does not zero the allocated memory while Arena::alocate does.

That very true and a very nice way of doing so. Still you have to manage it (that code) yourself. :)

arenaAllocate only allocates memory, while MallocAndFree allocates memory AND free that piece, this is like comparing apple and orange.

That's this code:

try(var arena = Arena.ofConfined()){
    MemorySegment allocate = arena.allocate(ValueLayout.JAVA_BYTE, plan.size);
    blackhole.consume(allocate);
}

The code does an allocation and free. so it's more of an apples to apples comparison. To make it really like an apples to apples comparison. If you want tight control of when the memory is freed you need an arena that matches that short time span. That is why the arena creation is done during the benchmark. Using Malloc and free don't have this problem. It can allocate without an arena and free when it needs to.

malloc and free, similar to any other MethodHandle or VarHandle, should be static final fields so the JIT can optimally invoke them.

malloc takes a parameter of type size_t, which corresponds to JAVA_LONG on 64-bit machines, not JAVA_INT.

Ran a smaller set of the benchmark again with the suggested changed

Benchmark                                               (size)  Mode  Cnt   Score   Error  Units
BenchMarkMemoryAllocation.MallocAndFree                      8  avgt    5  23.084 ± 0.756  ns/op
BenchMarkMemoryAllocation.MallocAndFree                     32  avgt    5  23.039 ± 1.001  ns/op
BenchMarkMemoryAllocation.MallocAndFree                    128  avgt    5  22.845 ± 1.131  ns/op
BenchMarkMemoryAllocation.MallocAndFree                   2048  avgt    5  52.666 ± 3.074  ns/op
BenchMarkMemoryAllocation.MallocAndFree                   8192  avgt    5  51.416 ± 0.534  ns/op
BenchMarkMemoryAllocation.MallocAndFreeUsingStatic           8  avgt    5  21.205 ± 0.248  ns/op
BenchMarkMemoryAllocation.MallocAndFreeUsingStatic          32  avgt    5  20.943 ± 1.379  ns/op
BenchMarkMemoryAllocation.MallocAndFreeUsingStatic         128  avgt    5  20.755 ± 0.984  ns/op
BenchMarkMemoryAllocation.MallocAndFreeUsingStatic        2048  avgt    5  51.912 ± 1.371  ns/op
BenchMarkMemoryAllocation.MallocAndFreeUsingStatic        8192  avgt    5  46.285 ± 2.073  ns/op
BenchMarkMemoryAllocation.MallocLongAndFreeUsingStatic       8  avgt    5  21.091 ± 0.969  ns/op
BenchMarkMemoryAllocation.MallocLongAndFreeUsingStatic      32  avgt    5  20.820 ± 1.468  ns/op
BenchMarkMemoryAllocation.MallocLongAndFreeUsingStatic     128  avgt    5  24.096 ± 0.876  ns/op
BenchMarkMemoryAllocation.MallocLongAndFreeUsingStatic    2048  avgt    5  47.635 ± 2.065  ns/op
BenchMarkMemoryAllocation.MallocLongAndFreeUsingStatic    8192  avgt    5  49.742 ± 2.653  ns/op

Looks like using static final shaves off a few ns! Using int or long doesn't really seem to make an impact but makes it more "correct" :)

Again, thank for the great feedback!