[foreign] from memory segments to byte buffers

[Maurizio Cimadamore]

On 23/03/2021 10:30, Chris Vest wrote:
> 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.
Yep - that is the current semantics
>
> 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.

Yeah - that's what we have in an experimental patch to support async BB IO.

Thanks for the feedback (both you and Remi) - overall, what I'm hearing 
is that the BB integration feels good as is, and that going back and 
forth between segments and buffers will be common, so our hands are tied 
when it comes to attaching "hidden costs" to the memory segment -> byte 
buffer conversion - e.g. such a conversion should not affect the 
properties of the original segment.

Maurizio

>
> On Mon, 22 Mar 2021 at 13:40, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto: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
>