[foreign-memaccess] RFC: split MemoryAddress and MemoryRegion

[Jorn Vernee]

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.

> * 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

---

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.

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).

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