<div dir="ltr"><div dir="ltr">Em qua., 2 de nov. de 2022 às 14:49, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> escreveu:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The main move described in the document is to make MemorySession a <br>
"pure" lifetime abstraction, thus dropping SegmentAllocator and <br>
AutoCloseable capabilities. Instead, these capabilities are provided by <br>
a *second* abstraction, called Arena. Crucially, an Arena _has_ a memory <br>
session, which can e.g. be used to allocate segments that have the same <br>
lifecycle as that of the arena. This subtle twist, gives us an API that <br>
is easier to reason about (and to build upon), and one where memory <br>
segments can be shared freely across clients - premature calls to <br>
MemorySession::close are no longer possible. At the same time, the API <br>
now makes a much clearer distinction between sessions that are closeable <br>
(i.e. sessions created through an Arena) and those that aren't (i.e. <br>
implicit and global sessions).<br>
</blockquote></div><div><br></div><div>IMHO, though the concern is clearly with reasoning about life-time, I think the design is improving in another direction, the specification of a clear, well defined, common memory allocator "service".</div><div>One of the most interesting features of the native linker API in my opinion is the existence of the SymbolLookup interface.<br></div><div>In the same sense that SymbolLookup is a "service", and CLinker its default or initial provider, I think there is great benefit in specifying Arena or SegmentAllocator as a "service", and something as its default provider.</div><div>Memory allocators are good candidates for injection by containers or frameworks, and natural mock targets in unit tests.</div><div>"frameworkized" applications which deal in direct ByteBuffers would play well with framework-injected memory allocators.</div><div>In the world of C, libraries like OpenSSL allow configuring its internal memory allocator, and replacing malloc entirely with alternatives such as jemalloc is not uncommon.</div><div>C++ has in recent years introduced the memory_resource abstraction to support the new polymorphic_allocator as an option for its template library; Boost has played with this for years.</div><div>Thank you very much for your hard work!</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>