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

[Radoslaw Smogura]

> (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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/foreign-memaccess+abi' into memory-pool-allocator
 - Code clean
   Fix tests
 - Prevent double adding element to queue
   
   Dealt with slow write issue - had to create segment with aligned size, not
   a bit shift.
   
   ForceInline allocatorForScope and allocate method - this is outcome
   from performance tests, and probable scalarization of segment.
   
   Some changes to inlining / no inlining.
 - Tests better distribute sizes for pseudo random allocation - now much larger buffers gets allocated and used.
   
   I'm bit puzzled here, as it looks like, that allocatioin is very fast, only
   reading is extreme slow.
   
   For comparision when processing single allocation:
   Update only first byte: direct pool access - 33ns, malloc / free: 59ns
   Update very 1024th byte: 12980ns, vs malloc: 8400ns
   
   I think simillar results has been spot during test with StringLen.
 - Better releasing resources on scopes close
   New benchamarks for bulk allocations
 - Minor fixes to SpinLockQueue
   Remove redundant LOCK release (set to 0) in put entry.
   Fixed maxSize comparison
   Removed unused imports
   
   Q: Could we reduce setRelease to just set in few places?
   Q: Should this method be private and moved to Entry.close to prevent accidental adding element from other queue?
 - 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
 - Fix tests (!)
   Make entries closable, to make API easier to use, and avoid searching for target queue.
   Replace atomics is var handles
 - Optimize bit bound calculations
 - Fix to copy-pasted test
 - ... and 2 more: https://git.openjdk.java.net/panama-foreign/compare/583abae0...2d0cb6c6

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/509/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/509/files/536e71aa..2d0cb6c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=509&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=509&range=08-09

  Stats: 110826 lines in 2397 files changed: 54078 ins; 49886 del; 6862 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/509.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/509/head:pull/509

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