dissecting memory sessions

Wed Nov 9 09:26:47 UTC 2022

On 09/11/2022 00:20, Uwe Schindler wrote:
>
> 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.
>
Leaving naming issues for now, I agree that perhaps names landed in a 
suboptimal state (esp. MemorySession).
>
>   * 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).
>
The parameter cannot be Arena. You might want to create a mapped segment 
that is managed by a global or an implicit session. In which case you 
have no arena. Or maybe you have another segment at hand, and you want 
to map a segment that has the same lifetime as the first segment. Again, 
you don't have an Arena.

All the API points that accept a "lifetime" need to accept a 
MemorySession. An Arena is a client-facing abstraction - it's what 
allows you to create a "bounded" lifetime - that is a lifetime that can 
start (when the arena is created) and end (when the arena is closed).

Maurizio

>  *
>
> 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/0cc6a056/attachment-0001.htm>