On Mon, 20 Jan 2025 17:34:45 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org>
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
>> line 112:
>>
>>> 110:
>>> 111: @SuppressWarnings("restricted")
>>> 112: public static MemorySegment acquireOrAllocate(long requestedSize) {
>>
>> An even higher-level alternative here would be for this method to return a
>> custom arena, whose `close` implementation does the `release`. This way, no
>> cleanup action is needed. The arena could use a slicing allocator on a
>> pre-allocated, per-thread segment. If the segment is not big enough for the
>> allocation the linker wants to do, we can just return a plain confined arena.
>
>> An even higher-level alternative here would be for this method to return a
>> custom arena, whose `close` implementation does the `release`. This way, no
>> cleanup action is needed. The arena could use a slicing allocator on a
>> pre-allocated, per-thread segment. If the segment is not big enough for the
>> allocation the linker wants to do, we can just return a plain confined arena.
>
> The observation here is that you have an acquire/release "lifetime". And then
> you have a client (the Linker) that wants to use the Arena API. So we could
> actually fold these two use cases, and create an Arena that has a better
> allocation strategy (because it recycles memory) and does the right thing
> when it is closed. This is kind of why custom arenas were allowed by the FFM
> API.
Maybe that's possible - I would at this point try to avoid making it too
general. I really only want to satisfy the Linker here, I only moved this code
out of the boundedArea method because of code size. I think this version sets a
good bar here for the overhead of a call-with-buffer: 5.5ns (over 3.3 w/o
buffer) and zero allocations; we can work against that with new designs.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922732833
