RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v4]
Matthias Ernst
duke at openjdk.org
Mon Jan 20 18:13:54 UTC 2025
On Mon, 20 Jan 2025 17:34:45 GMT, Maurizio Cimadamore <mcimadamore at 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
More information about the core-libs-dev
mailing list