Feature requests.

[Lee Rhodes]

I'm not sure this is the right forum for this. Let me know if this should
be directed elsewhere. 🙂

*1. Easier memory alignment when creating segments on-heap.*

Our library wants to treat on-heap and off-heap MemorySegments
identically.  But there is asymmetry in the APIs for creating segments
on-heap vs off-heap.

Currently the only way, that I am aware of, to ensure that an on-heap
segment is created with the proper alignment is to create it with an
primitive array of the desired natural alignment.  For example, suppose I
want to create an on-heap segment of a 9 byte struct consisting of a long
and a byte.  If I want the long to be properly memory aligned, I have to
allocate the on-heap segment with *MemorySegment.ofArray(new long[2]) *instead
of *MemorySegment.ofArray(new byte[9]).withAlignment(8)*, which would be
much more natural and convenient, particularly with more complex structs.
The effective memory usage of these two approaches is probably the same. So
this request is not for memory efficiency, per se.

Suppose I need to access pairs of doubles (e.g., complex numbers, or
128-bit floating point values) and I would like these objects to be memory
aligned to 16 bytes.  That is easy to do off-heap, but how would I do that
on-heap?

*2. Accessible configuration parameters for Arena.*

It would be useful to be able to determine the type of a given Arena.  For
example, given an Arena, is it Global, Auto, Confined or Shared?  A simple
*getArenaType()* would work.  To do this today I would have to extend
*Arena*, with a separate tracking variable for the type created, but it is
unclear to me if that extended arena would provide the same "strong
thread-safety, lifetime and non-overlapping guarantees".

*3. An idempotent option to close an Arena.*

Having an additional idempotent *Arena::close()* option such as an Arena::
*closeIfCloseable()* method.  This would check if the type of arena can be
closed (see above) and if the arena is *alive*, and, if true, would
atomically (thread-safe) close the arena.

The reason for this request is that in large systems the knowledge that a
resource can be closed can be quite remote from the application, process,
or code that allocated the resource.  Given that there may be multiple
Arenas active in a system it would be convenient to have a common method
that would close any Arena, if it is closeable, without throwing
exceptions.  Given the current design, a system must separately track each
Arena and its type, and conceivably have to separately track every
MemorySegment allocated by each Arena and the state of each segment.

The API Note in the *Close()* documentation states:


> This operation is not idempotent; that is, closing an already closed arena
> *always* results in an exception being thrown. This reflects a deliberate
> design choice: failure to close an arena *might* reveal a bug in the
> underlying application logic.


The design decision to make it *not idempotent* seems to be presumptive
given the rationale that "failure to close an arena *might* reveal a bug
...", *and* there are no other alternatives. Because it *might not* reveal
a bug in the application logic.

I'm not suggesting any change to the current *close*() method.  This is a
request for an idempotent alternative.

I'm expecting 1) vociferous disagreement on this one 🙂,  or 2) at least a
more comprehensive rationale as to why the ability to close arenas is so
limited.

Cheers,
Lee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250515/abc1d31a/attachment.htm>