[foreign-memaccess+abi] RFR: 8270376: Finalize API for memory copy [v9]

[Maurizio Cimadamore]

My first reaction is that the scope belongs to the Parent, while the 
allocator belongs to the Aggregator.

Or maybe the Aggregator has a link to the Parent.

I get that you want aggregator to be a simple thing that only works off 
a memory segment - and avoid passing extra parameters; but I think there 
is a more important question here which is whether your API wants to 
expose memory segments directly, or not, to clients.

A memory segment is a relatively neutral entity (like a ByteBuffer), and 
I think that, in general, if you feel like you need to add more 
semantics to a segment, you are probably better off creating your own 
abstraction which has a segment inside (which is used for low level 
memory operations).

If this was a normal API I'd say: sure, you can extend MemorySegment and 
ResourceScope, and add whatever you want in there. But that's not going 
to work: if you extend MemorySegment (e.g. to add a "parent" pointer) 
all VarHandles/MethodHandles taking a MemorySegment will be way less 
efficient, because you have lost exact type match with the VH/MH 
signature (e.g. the VH takes a MemorySegment, but you are passing a 
LeeSegment which is a subclass of MemorySegment).

This (coupled with safety concerns) are the reasons as to why 
inheritance is mostly a no go in the API.

Maurizio

On 12/08/2021 00:20, leerho wrote:
> Yes, now I remember. Thank you.  I apologize for the redundant 
> request.  Nonetheless, I guess I am having difficulty in figuring out 
> how to use this allocator in our use case.  Let me try an elementary 
> example.
>
>     public class Parent {
>
>       MemoryScope scope = defineScope(...);
>       MemorySegment arena = defineArenaSegment(..., scope);
>       MemorySegment[] segArr = //allocate a large number of segments
>     as slices of arena
>
>       Aggregator[] aggArr = //array of aggregators that operate each
>     in their own segment
>       for (int i=0; i < segArr.length(); i++) {
>         aggArr[i] = new Aggregator(segArr[i]);
>       }
>
>       //Start the process of updating all the aggregators with data.
>     The parent has no clue as to 
>
>       // which aggregators will need more memory. 
>
>
>       public class ParentAllocator extends SegmentAllocator {
>         @Override
>         public MemorySegment allocate(long bytesSize, long
>     bytesAlignment) {
>           ...
>         }
>       }
>     }
>
>
>     public class Aggregator {
>
>
>       public Aggregator(MemorySegment seg) {}
>
>
>       public void update(data) {
>         //oops, my segment is full.  I need a larger segment.
>         //How do I access ParentAllocator? Unless I pass it along with
>     the segment?
>       }
>
>
> }
>
> On Wed, Aug 11, 2021 at 2:44 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     I've resurrected an older conversation here:
>
>     https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/013191.html
>     <https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/013191.html>
>
>     At that time we discussed using a custom allocator to track
>     allocation
>     pressure. I think that's still the way to go.
>
>     Adding more features on ResourceScope is IMHO not the way to go,
>     given
>     that a ResourceScope is not used just for memory segments. If you
>     want
>     to keep track of how much memory is allocated, likely you need a
>     custom
>     allocator which has the ability to do that, and react accordingly,
>     which
>     is why the SegmentAllocator is there. Note that a SegmentAllocator
>     can
>     be built on top of a scope, e.g. you don't have to give up scopes
>     (see
>     what we do for arena allocators): e.g. you start with a scope,
>     wrap it
>     into an allocator and then use the allocator.
>
>     Maurizio
>
>     On 11/08/2021 22:29, Maurizio Cimadamore wrote:
>     > I have to admit, I have trouble understanding what you are
>     proposing -
>     > e.g. what this callback would be for. What calls to resource
>     scope do
>     > you wish to intercept?
>