[foreign-memaccess] RFR: Preserve memory scope for buffer segments

[Ty Young]

On 4/16/20 5:54 AM, Maurizio Cimadamore wrote:
> Not 100% sure about this, but wanted to share this PR for evaluation. Basically, I've realized that we are also not
> preserving the memory scope of the original segment when we do a segment -> buffer -> segment transition.
>
> This means that, e.g. code like this:
>
> MemorySegment segment = MemorySegment.allocateNative(16);
> segment = MemorySegment.ofByteBuffer(segment.asByteBuffer());
> segment.close(); // no cleanup of native memory
>
> will not really 'close' the original segment. Similarly, if the original segment is being worked upon by some other
> thread (through a spliterator) it is possible for the morphed segment to lose this info, and to allow a close - if the
> scope is created afresh (as is now).
>
> This patch fixes this, but I'm torn as to whether it makes things better; preserving access modes and thread ownership
> is mostly about not allowing clients to use the byte buffer escape hatch as a way to defy the segment restrictions. I
> don't think preserving scope falls into the same bucket - e.g. this is a separate question as to whether a segment S2
> obtained through S1 -> BB -> S2 is just a *view* of S1 (with same temporal bounds), or is just an independent segment,
> with new temporal bounds. I think both answers are legitimate, and it's mostly a question of making up our mind.
>
> My take is that inferring scope like this can be seen a bit too magic - and you are never sure of what happens when you
> do a MemorySegment::close, so perhaps what we have w/o this patch is preferrable. What do you think?
>

FWIW, I really think it should be a view.


Reason being is that, if it's possible to get a ByteBuffer from a 
MemorySegment or vice versa, then they both contain the same basic 
information and should be able to be used interchangeably or made copies 
of each other without any side affects.


(and yes, this means closing a ByteBuffer will also close segments)


This idea of "reproducable" objects is something that I've unknowingly 
allowed in my abstraction:


NativeLong original = new NativeLong();
NativeLong copy = new NativeLong(original.getAddress());

copy.setValue(Long.MAX_VALUE);

System.out.println(original.getValue());


...and while it's wasteful it makes sense to support this, at least to 
me. You're just reusing data that already exists, so why would anything 
be different? Maybe that isn't how things work under the hood on FMA's 
end, I don't know, but this model as an API user makes more sense IMO.


...which, as a side note, is why I thought all of my classes could be 
converted to Records since they seem to be one in of the same as 
"reproducable" objects.