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

[leerho]

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


Indeed, that is the natural reaction from the object-oriented paradigm
whereby the client object owns and manages its own memory.  But this use
case is different.

I think there is a more important question here which is whether your API
> wants to expose [the allocation and deallocation of] memory segments
> directly, or not, to clients. ( [ ] my interpretation of what you meant )


Indeed.  In the case I am trying to explain, the allocator clearly needs to
belong to the Parent.  The parent is the one managing and tracking overall
memory consumption of the system and there can be millions of aggregators.
The strategy of how to manage memory can change based on load conditions.
For example, the parent may choose to redirect incoming data to another
node in the cluster to reduce memory pressure on a particular node; or
transfer some of the demand for off-heap memory onto the heap, etc.  This
is why the interface we designed for dealing with this issue is a *request*
for a larger segment from the client to the parent.  The parent can then
determine how and where that request can be served based on issues at the
system level.

Thank you for your explanation wrt not allowing inheritance.  It makes
sense.

Cheers,
Lee.

On Thu, Aug 12, 2021 at 2:38 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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> wrote:
>
>> I've resurrected an older conversation here:
>>
>> 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?
>>
>