dissecting memory sessions

[Pedro Lamarão]

Em qua., 2 de nov. de 2022 às 14:49, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> escreveu:

The main move described in the document is to make MemorySession a
> "pure" lifetime abstraction, thus dropping SegmentAllocator and
> AutoCloseable capabilities. Instead, these capabilities are provided by
> a *second* abstraction, called Arena. Crucially, an Arena _has_ a memory
> session, which can e.g. be used to allocate segments that have the same
> lifecycle as that of the arena. This subtle twist, gives us an API that
> is easier to reason about (and to build upon), and one where memory
> segments can be shared freely across clients - premature calls to
> MemorySession::close are no longer possible. At the same time, the API
> now makes a much clearer distinction between sessions that are closeable
> (i.e. sessions created through an Arena) and those that aren't (i.e.
> implicit and global sessions).
>

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".
One of the most interesting features of the native linker API in my opinion
is the existence of the SymbolLookup interface.
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.
Memory allocators are good candidates for injection by containers or
frameworks, and natural mock targets in unit tests.
"frameworkized" applications which deal in direct ByteBuffers would play
well with framework-injected memory allocators.
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.
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.
Thank you very much for your hard work!

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221110/ea47fb35/attachment.htm>