Can we have some heap segment allocation API in the future?

[Maurizio Cimadamore]

On 28/03/2024 01:55, 刘希晨 wrote:

> So in my opinion, it's better if JDK could provide a mechanism, to 
> allocate a heap MemorySegment, with given byteSize and byteAlignment, 
> without zeroing, for these use cases.

This seems questionable. Note that FFM doesn’t even provide an 
allocation for /off-heap/ memory that avoids the zeroing. That is, 
zeroing is only avoided when the API determines that the memory contents 
are going to be overwritten anyways (e.g. using one of the 
SegmentAllocator::allocateFrom methods).

If I were to write something like this, I would try to allocate long[] 
in “slabs” and then recycle the slabs as needed.

You probably need some kind of “heap pool” abstraction, which can be 
used to request “scoped arenas” out of it - e.g.

|HeapPool pool = new HeapPool(...) ... try (Arena arena = pool.arena()) 
{ ... } // return memory to the pool |

This is generally possible - but the lack of support for 
|MemorySegment::reinterptet| for heap segments makes it hard to make 
this 100% safe. But, once you’re down this rabbit hole, and managing 
memory manually this way, does it really make a difference if the outer 
pool is backed by long[] vs. off-heap memory?

In general, passing heap segments to native function is supported for 
API compatibility reasons: e.g. you might have an API that is already 
specified in terms of byte[], but then want to use this API to call some 
native function. Sometimes the cost of copying memory back and forth is 
too prohibitive, hence the “critical” linker option.

But if you are writing code from scratch, there are, I believe, good 
ways to recycle /off-heap/ memory that do not require to touch heap 
memory (which has other limitations). For instance, one of the items in 
my todo list is to build a fast stack-like allocation arena, which 
allows for fast allocation and recycle (push/pop). I think arenas like 
that would go a long way to avoid use of heap memory when not really 
required.

Cheers
Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240405/6cb36a63/attachment-0001.htm>