[foreign-memaccess] RFC: split MemoryAddress and MemoryRegion

[Maurizio Cimadamore]

On 17/05/2019 18:19, Jorn Vernee wrote:
> I like this idea. (tbh I wasn't too enthusiastic about merging the 2 
> in the foreign impl either, but wanted to see how it went). About the 
> disadvantages:
>
>> * one more API point
>
> Like you say; "methods 'feels' where they belong", I think this is 
> more important than having a smaller API.
yeah
>
>> * MemoryScope::allocate returns a region, which has then to be turned
>> into a MemoryAddress (of course we could always project into address,
>> but it seems more general for allocation to return the region)
>
> What about having 2 allocation methods, one which takes a Layout and 
> which returns a MemoryAdress, and one which takes a byte size and 
> returns a MemoryRegion?
>
>     MemoryAddress allocate(Layout layout);
>     MemoryRegion allocateRegion(long size);
>     // + overloads with alignment
This might be a good idea - after all low-level users might even not 
want to bother with layouts... seems a sensible suggestion.
>
> ---
>
> About the implementation; I think for now we want to just get rid of 
> MemoryBoundInfo.ofEverything, as well as MemoryAddressImpl.ofNative, 
> since they're not really needed right now. If we want to expose the 
> size of a memory region, we can't use MemoryBoundInfo.ofEverything any 
> ways since the length it uses is bogus.
Yeah there's loads of stuff in the impl in need of cleanup, most of what 
you see here was set up in preparation for later stages, but now that we 
found a simpler center for the API, it's time to revisit the impl too.
>
> I think down the road for native pointers we'd want to use a null 
> MemoryRegion i.e. have no scope and range checks for those. If 
> attaching a scope to a native pointer is still desirable, we might 
> want to put the scope() method in MemoryAddress after all, since some 
> pointers would have a scope, but not a memory region (i.e. no range 
> checks).

Yep - I'll keep that in mind.

Maurizio

>
> Jorn
>
> Maurizio Cimadamore schreef op 2019-05-16 19:28:
>> Hi,
>> this is not an official RFR, as much a request for comments; in the
>> past I've mentioned the possibility of separating the region-like
>> aspects of MemoryAddress into a separate abstraction (MemoryRegion),
>> as users can be confused by the dual nature of MemoryAddress. An
>> example of this split is below:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/split-region/
>>
>> Splitting seems to lead to a generally clearer API:
>>
>> * methods 'feels' where they belong (e.g. resize() is on region)
>> * Address implementation becomes even smaller (offset + region)
>> * Having an explicit MemoryRegion thingie will give us a natural
>> carrier for 'compound' layouts, which can be useful later on (e.g.
>> foreign functions)
>>
>> Disadvantages are:
>>
>> * one more API point
>> * MemoryScope::allocate returns a region, which has then to be turned
>> into a MemoryAddress (of course we could always project into address,
>> but it seems more general for allocation to return the region)
>>
>> Comments?
>>
>> P.S.
>>
>> I'm not married to the MR/MA names, so if the main objection against
>> this split has to do with naming, I'm open to discuss alternatives. On
>> the other hand, I've tried to think about other names for MemoryAddres
>> which could handle better its dual nature - and I'm not convinced we
>> can resolve the ambiguity with a simple name change.
>>
>> Cheers
>> Maurizio