dissecting memory sessions

[Maurizio Cimadamore]

On 10/11/2022 13:21, Rémy Maucherat wrote:
> Ok, so initially I was a bit confused by the API change, but overall
> it seems good. The only item which feels weird to me is with implicit
> memory sessions, which are now using a different API than confined or
> shared.

Hi Remy, thanks for the feedback.

I believe there is always going to be some element of discomfort, due to 
the fact that we're trying to model a world where _some_ lifetimes can 
be controlled by clients (who can call close) and _some_ cannot be 
controlled (as implicit).

If you use same API in both cases, as we did in Java 19, then you end 
with issues where close throws an exception (so an implicit session 
doesn't _really_ implement the MemorySession interface). Moreover, since 
a session is an AutoCloseable in Java 19, you get all sort of issues 
when operating on an implicit session, as IDEs and compilers will 
constantly remind you that you are using an AutoCloseable w/o a 
try-with-resources - but you can't really fix it (in fact, using a 
try-with-resources would lead to an exception on close!).

The split we propose more honestly reflects this difference: there are 
cases where users would want to control the lifetime, and simpler cases 
where users are not interested in controlling the lifetime. In the 
former case, you need to use an Arena, which is AutoCloseable, and can 
be closed. In the latter case you just use an implicit session (or a 
global one), and don't need any try-with-resources. This results in an 
API where you can still look at a segment, and reason about its lifetime 
(by looking at its session), while, at the same time, making sure that 
clients of that segment have no way to go back from the segment lifetime 
to the arena (which introduces all sort of issues when trying to build 
custom abstractions on top of the FFM API).

I believe the "weirdness" you are referring to is caused by the fact 
that we come to this new API a bit biased by what the API used to do 
before. But if you squint, the API is actually uniform, in the sense 
that when you allocate/map/... a segment, you have to provide a session 
for the segment.  Sometimes, this session will be global (e.g. no 
deallocation). Other times the session will be implicit (GC, please 
deallocate for me). Or, the session might come from an arena (e.g. I 
want to be in control of when deallocaton happens). But a segment has 
always a session (the only thing that changes is how that session is 
produced).

Maurizio