[foreign-memaccess] RFC: split MemoryAddress and MemoryRegion

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu May 16 17:28:58 UTC 2019


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



More information about the panama-dev mailing list