[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