[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