[foreign] from memory segments to byte buffers

[Chris Vest]

In Netty, since ByteBuffer (at least currently) is the currency of IO, we
would indeed have to create byte buffer views from our shared memory
segments.
Giving up deterministic deallocation because of this would be unfortunate.
I have been thinking of the byte buffer views as simple views onto the
underlying memory segment, where keeping the byte buffer around for longer
than the life time of the segment would just produce errors on access to
the buffer.
Similar to how a memory segment might behave if it was kept around after
being closed, or after its scope has been closed.

When it comes to IO operations, asynchronous or otherwise, where the memory
becomes referenced externally, I think it is the operation - not the byte
buffer - that should acquire on the segment and release back on completion.

On Mon, 22 Mar 2021 at 13:40, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> after putting together the PR for the ResourceScope abstraction [1] it
> occurred to me that, perhaps, support for byte buffer views in the
> memory segment API is more complex than it needs to be.
>
> Currently, when creating a byte buffer out of a memory segment, we need
> to save the segment scope in the buffer, and apply scope checks whenever
> the buffer is accessed. Among the things the scope check will enforce,
> the most important ones are:
>
> * confinement check: if the scope associated with the segment from which
> the buffer has been derived is confined, make sure that the buffer is
> accessed from same thread
> * liveness check: if the scope associated with the segment  from which
> the buffer has been derived is closed, access to the buffer is not allowed
>
> Since in the previous API there was no way to disallow a call to
> MemorySegment::close, the only way we had to enforce correctness on the
> buffer was to apply same scope checks we applied on memory segments.
> When combined with the ability of also creating a segment from a byte
> buffer (the dual case), this makes for some convoluted code, as we have
> to ensure that doing segment -> buffer -> segment gives you back the
> same scope you started with.
>
> Now we have, possibly, a new weapon: when creating a byte buffer view
> from a segment, we could acquire the segment. This would mean that the
> segment would remain non-closeable as long as the buffer view (or any
> slices derived from it) are reachable.
>
> This would solve all issues related with liveness - but there would
> still be problems when it comes to confinement. Here we have some options:
>
> * disallow creating a byte buffer view from a confined segment - after
> all, the byte buffer API is not confined (note that for segments created
> using the so called "default scope" this restriction would not apply,
> since default segments are shared)
> * still allow creation of BB views from confined segments, but insert
> confinement checks where needed
>
> What do people think about this simplification? How important it is to
> retain deterministic deallocation in the face of byte buffer views? One
> clear advantage of dropping that use case is that no further change
> would be required to the BB API in order e.g. to support async file
> system operation: since a byte buffer now would keep the originating
> scope open, there would be no fear of the memory backing the byte buffer
> disappearing while performing some async IO on it.
>
> The drawback is that if anything inside an application requires some
> conversion from a segment into a BB (e.g. to interop with some legacy
> library), that conversion has a potential of affecting deterministic
> deallocation of the segment, from code which might be oblivious to the
> fact that somewhere some BB view has been created (and maybe the BB has
> already been operated on, so there's no "bug" in the application, but
> the GC/Cleaner might be slow at triggering the ReosurceScope release
> operation).
>
> We can of course keep everything as is (as we have done most of the
> work) I just wanted to make sure we understood the complexity of what
> the impl does today, and make sure this complexity was necessary.
>
> Maurizio
>
>