[foreign-memaccess+abi] RFR: MemorySegmentPool + Allocator [v11]

[Maurizio Cimadamore]

On Sat, 24 Apr 2021 01:25:56 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:
> 
>   Adjust to latest changes
>   Remove direct API
>   Prevent keeping hard reference to shared scope, through chain cleaner, pooled allocator, pool scope

I agree the latest version looks much cleaner - I think you can simplify the MemoryPoolItem further, by just storing an address and move all cleanup logic in CleanerRunnable (which would be run when the pool scope is closed).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegmentPool.java line 316:

> 314:       this.sourceAddress = sourceAddress;
> 315: 
> 316:       ((ResourceScopeImpl) scope).addOrCleanupIfFail(new ResourceCleanup() {

Not 100% sure you need this. You already have added a cleanup action which calls `ClearRunnable`. Why not just deallocating stuff from there? In fact, I think the scope should be also moved to the spin lock queue - each queue has a scope, and when the scope is closed, the queue is locked, and all entries inside it are released. This will save a cleanup action addition on every new memory pool item (that's how I'd do it at least).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/509