dissecting memory sessions

Wed Nov 9 00:20:26 UTC 2022

Hi,

sorry for the late reply (I was privately discussing with Maurizio 
already). From the Lucene standpoint only using MemorySegment on top of 
mmapped files, I see no problems, we just need to replace MemorySession 
by Arena in our code (I plan to change our code to use just pass 
Autocloseable around to allow us to unmap shared  mmaped files).

But when looking at the API I found some minor problems:

  * Naming: "MemorySession", "MemorySegment".... but now "Arena". I'd
    rename it to "MemoryArena" to make it consistent. Personally I have
    my problems with the term "Arena", to me it makes it hard to understand.
  * In Lucene we work with MMap mainly - I did not look into other parts
    on Panama, but for memory mapping I was wondering about the
    signature of FileChannel#map(..., MemorySession). The last parameter
    is currently a MemorySession and was not changed to Arena. IMHO,
    this should be Arena, because to me it looks like an *allocation* of
    a mapped file slice and goes in line with other allocatior methods.
    You use an Arena as factory for MemorySegments. FYI, in our current
    code in Lucene when we pass Arena around, we need to get the Session
    from it first. For newcomers this is hard to understand, because the
    MemorySession has lost importance and is no longer a first class
    citizen to get. Its hard to figure out how to get the session. Also
    the code that maps the file should be under control to unmap it and
    for that the arena is important. With the session alone you cannot
    unmap it. So to me mmap a segment and releasing it should use same
    class (Arena).

Uwe

Am 02.11.2022 um 18:48 schrieb Maurizio Cimadamore:
> Hi,
> After the first preview of the FFM API in Java 19, we have identified 
> a couple of areas where the API could use some improvements:
>
> * Clarify the relationship between MemorySegment and MemoryAddress 
> (this was addressed in [1]); and
> * Polish the MemorySession API, and make segments easier to (safely) 
> share with external clients (what this email is about).
>
> While we have explored solutions to better encapsulate memory sessions 
> in the past (e.g. by dropping session accessors, as described in [2]), 
> nothing seemed to stick. So, for Java 19 we decided to leave session 
> accessors on memory segments in place, but give the option to 
> libraries to protect against "sneaky" close, by creating non-closeable 
> memory session views.
>
> After staring at this problem long enough, it became increasingly 
> clear that memory sessions, in their current shape and form, are 
> trying to do too much - from allocation, to lifecycle management and 
> more. The issue with "sneaky" close is mostly a manifestation of that 
> more fundamental problem. In that spirit, we have put together a 
> document which teases apart the various "traits" associated with 
> memory sessions, and repackages the same traits into an API that 
> provides better encapsulation and composition. The document can be 
> found here:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html
>
> 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).
>
> Here's a list of the main API changes, and how they will impact 
> clients of the FFM API:
>
> * MemorySession no longer has a close() method; try-with-resources 
> against MemorySession will now need to use Arena instead;
> * Support for non-closeable session views 
> (MemorySession::asNonCloseable), and related methods 
> (MemorySession::equals/hashCode) has been removed;
> * MemorySession::addCloseAction has been removed; instead, clients can 
> specify a cleanup action when creating an unsafe segment (i.e. using 
> MemorySegment::ofAddress);
> * Some of the predicates in MemorySession have been made more robust - 
> e.g. instead of MemorySession::ownerThread(), there is now a predicate 
> MemorySession::isOwnedBy(Thread).
>
> After careful consideration, we believe that the changes described in 
> this document are worth pursuing for the upcoming Java 20 integration 
> [3]: they make the API more principled (no more "sneaky" close), while 
> retaining a similar expressive power.
>
> Any feedback is greatly appreciated.
>
> Cheers
> Maurizio
>
> [1] - 
> https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html
> [2] - 
> https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html
> [3] - 
> https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html
>
>
-- 
Uwe Schindler
uschindler at apache.org  
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221109/e4f2576c/attachment-0001.htm>