<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi again Lee!<br>
<br>
1.<br>
<br>
The VM/GC has its own rules for how arrays are allocated, and so, there is no way (at least not now) to control primitive array alignment except for the way you mentioned — a primitive array is always aligned to its component's natural alignment. A very simple
way to allocate and align heap arrays could be to implement a method similar to this one:<br>
<br>
<br>
<span style="font-family: monospace;">static MemorySegment heapSegment(MemoryLayout layout) {<br>
byte[] arr = new byte[(int) layout.byteSize() * (int)layout.byteAlignment() - 1];<br>
SegmentAllocator allocator = SegmentAllocator.slicingAllocator(MemorySegment.ofArray(arr));<br>
return allocator.allocate(layout);<br>
}</span><br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If memory efficiency is a concern, a more complex solution can be written that leverages the implicit alignment of arrays of
<code>int</code> and <code>long.</code></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
2.<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The <code>Arena </code>interface is not sealed. So, anyone can write their implementation that typically delegates to one of the out-of-the-box
<code>Arena</code> types provided by the JDK. The question then becomes: What arena type should such a bespoke Arena return? I am not sure why you need to be able to determine the
<code>Arena</code> type, but there are some (legal) tricks that can be used:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul data-editing-info="{"applyListStyleFromLevel":true}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div class="elementToProof">If the <code>arena</code> is identical to <code>Arena.ofGlobal()</code>, then the arena type is global (as there is, by definition, only one
<code>Global</code> arena).</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div class="elementToProof">If, on another (private) thread, invoking <code>isAccessibleBy(Thread thread)
</code>returns<code> false, </code>on a segment allocated from the arena, it is a Confined Arena or a bespoke Arena, which delegates to a Confined Arena.</div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There are other hacky ways (that are not future-proof) to figure out the arena type that I do not want to mention here. Maybe someone else can come up with a clever way to legally figure out the rest without closing the arena? What is the use case for this?
Maybe it is related to 3.? If you have full control of your application, I suggest that you implement your own arena type. I do not see any safety implications with this.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
3.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The non-idempotency of the <code>close()</code>operation was discussed on several occasions during the design process of the FFM API. The choice was deliberate, as not knowing if an arena should be closed or not often reveals subtle edge cases in the code (e.g.,
a resource is transferred to another owner, but the original owner is unaware of this). Again, you can create your own arena that has an idempotent close operation or adds a
<code>tryClose()</code> operation that returns if/if not the arena was closed:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
<br>
<span style="font-family: monospace;">if (arena instanceof MyArena ma) {<br>
ma.tryClose();<br>
}</span></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
As a blunt last resort, you can always catch the exception of a failed <code>close()</code> operation.<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Adding a <code>tryClose()</code> operator to the API would raise compatibility issues with bespoke implementations of the
<code>Arena</code> interface, which are already out in the wild. Adding a default
<code>tryClose()</code> method might, in such cases, depend on catching exceptions, which is slow if an exception is actually thrown.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
I am not sure my answer to this last bullet meets your expectations, but I hope you might be able to pick up some ideas.<br>
<br>
Best, Per Minborg<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> panama-dev <panama-dev-retn@openjdk.org> on behalf of Lee Rhodes <leerho@gmail.com><br>
<b>Sent:</b> Friday, May 16, 2025 1:35 AM<br>
<b>To:</b> panama-dev@openjdk.org <panama-dev@openjdk.org><br>
<b>Subject:</b> Feature requests.</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">I'm not sure this is the right forum for this. Let me know if this should be directed elsewhere. 🙂</div>
<div dir="ltr"><br>
</div>
<div><b>1. Easier memory alignment when creating segments on-heap.</b><br>
<br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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
<i>MemorySegment.ofArray(new long[2]) </i>instead of <i><b>MemorySegment.ofArray(new byte[9]).withAlignment(8)</b></i>, 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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div><b>2. Accessible configuration parameters for Arena.</b></div>
<div><br>
</div>
<div>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
<i><b>getArenaType()</b></i> would work. To do this today I would have to extend
<i>Arena</i>, with a separate tracking variable for the type created, but it is unclear to me if that extended arena would <span style="color:rgb(40,40,40); font-family:"DejaVu Serif",Georgia,"Times New Roman",Times,serif; font-size:14px">provide the same "strong
thread-safety, lifetime and non-overlapping guarantees". </span></div>
<div><br>
</div>
<div><b>3. An idempotent option to close an Arena.</b></div>
<div><br>
</div>
<div>Having an additional idempotent <i>Arena::close()</i> option such as an Arena::<i><b>closeIfCloseable()</b></i> method. This would check if the type of arena can be closed (see above) and if the arena is
<i>alive</i>, and, if true, would atomically (thread-safe) close the arena. </div>
<div><br>
</div>
<div>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. </div>
<div> </div>
<div>The API Note in the <i>Close()</i> documentation states:</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<span style="color:rgb(40,40,40); font-family:"DejaVu Serif",Georgia,"Times New Roman",Times,serif">This operation is not idempotent; that is, closing an already closed arena </span><em style="color:rgb(40,40,40); font-family:"DejaVu Serif",Georgia,"Times New Roman",Times,serif">always</em><span style="color:rgb(40,40,40); font-family:"DejaVu Serif",Georgia,"Times New Roman",Times,serif"> results
in an exception being thrown. This reflects a deliberate design choice: failure to close an arena
<b><i>might</i></b> reveal a bug in the underlying application logic.</span> </blockquote>
<div><br>
</div>
<div>The design decision to make it <i>not idempotent</i> seems to be presumptive given the rationale that "failure to close an arena
<b><i>might</i></b> reveal a bug ...", <b>and</b> there are no other alternatives. Because it
<i><b>might not</b></i> reveal a bug in the application logic.</div>
<div><br>
</div>
<div>I'm not suggesting any change to the current <i>close</i>() method. This is a request for an idempotent alternative. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lee.</div>
<div><br>
</div>
<div><br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</body>
</html>