[foreign-jextract] RFR: MemorySegmentPool + Allocator [v5]

[Maurizio Cimadamore]

On Tue, 20 Apr 2021 10:53:21 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:

> Malloc / free actually use internally some good optimized algorithms.
> 
> (I briefly checked implementation of malloc and it sometimes uses arenas to allocate memory, I think that zeroing can happen due to system allocating zeroed page).

I don't think malloc concerns with zeroing - calloc does (and yes, calloc exploits behavior of mmap to avoid redundant zeroing when requesting large allocations).
> 
> However, AFIK, malloc / free have a tendency to fragmentize memory, and generally C guys avoids it due to fragmentization of memory.
Sure, I guess my point was more related on the need of a custom allocator in your specific case - there are many sources for overhead associated to MemorySegment::allocateNative:

* memory zeroing (cost grows linearly with allocated size)
* update memory limits (2 CAS on allocation, 2 CAS on free)
* some memory checks in Unsafe::allocateMemory
* alignment checks and slicing
* cost of malloc/free

If you just call "malloc" as is (CLinker::allocateMemory) - and then wrap the results in a segment (MemoryAddress::asSegment) the numbers you get are typically quite good (this is, essentially, what the `unsafe` benchmark does). So the question is: have you tried something like this with your IO implementation and see which numbers are coming out? In other words, are you sure that the reasons you are trying to avoid malloc/free have to do with malloc/free themselves, rather than to the extra overhead/bookkeeping added by `MemorySegment::allocateNative` ?

Of course, if you have experienced fragmentation issues with malloc, the ideas above are not going to help, and I agree that a better allocator is needed.

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

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