[foreign-jextract] RFR: MemorySegmentPool + Allocator [v6]
Maurizio Cimadamore
mcimadamore at openjdk.java.net
Tue Apr 20 17:22:14 UTC 2021
On Tue, 20 Apr 2021 15:36:47 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:
>> (Preview)
>>
>> The MemorySegmentPool is a pool maintaining memory segments, optionally can expose allocator which can be bound to other scope, and which will return allocated segments back to pool.
>>
>> However the best results has been achieved by using getSegmentEntry & putSegmentEntry methods.
>>
>> The pool is intended to be used by long running applications (i.e. like global shared pool), where fast allocation and de-allocation of segments is critical (was designed during implementation of I/O subsystem with Panama, as a pool for temporary buffers between system I/O methods and Java byte arrays from InputStreams).
>>
>> The pool uses hand-made SpinLockQueue as the Deque from JDK offers too much functionality and overhead.
>
> Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision:
>
> Use VH insted of volatile
>
> Replacee
> // while ((int) LOCK.compareAndExchange(this, 0, 1) != 1) { }
> while (!LOCK.compareAndSet(this, 0, 1)) { }
>
> Performane around 34 ns / oop
src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegmentPool.java line 179:
> 177:
> 178: public static class MemoryPoolSegment extends SpinLockQueue.Entry<MemoryPoolSegment> implements AutoCloseable {
> 179: private final NativeMemorySegmentImpl memorySegment;
I think this should be MemoryAddress, and the scope should be "late bound" when a segment is retrieved from the queue and requested by a client. Otherwise clients get segments with a different scope than the one they are in - which in itself is ok, but I think it's counterintuitive for an allocator associated with a scope to return segments that last longer than that scope.
In fact I'm not even 100% that you need a scope for the pool itself (which could mean that the acquire is not needed).
-------------
PR: https://git.openjdk.java.net/panama-foreign/pull/509
More information about the panama-dev
mailing list