<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="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>