[foreign-memaccess] on confinement

[Maurizio Cimadamore]

On 04/06/2019 17:03, Maurizio Cimadamore wrote:
> Note: I'm not saying this will be trivial to implement correctly - but 
> what I like about this is that the programming model will look 
> relatively clean in comparison to something like (1). Essentially you 
> can slice and dice all you want, and, as long as you are asking 
> reasonable questions, things will work with decent performances. 

Quick update; I've been doing some experiment on this - it doesn't look 
pretty for now.

Some of the issues we have to take into account:

* as discussed, we want the master region to somehow keep track (via its 
mutable 'scope-like' object) of the sub-regions

* if we share the same scope for all subregions (which we probably want 
to avoid too much allocation on resize) then we need to have a way for 
the sub-region to perform an efficient confinement check - one trick I 
used was to give each sub region an unique index, and then use the index 
to access a subregion 'ownership' array

* we need to take into account regions being GCed - otherwise the lists 
kept into the master region will (potentially) grow w/o bounds

* we need to take into account synchronization when adding/removing 
sub-regions - this is probably not a big concern given that these 
operations occur during a 'resize' or when a region is being GC, so the 
memory access itself can still be fast

* since we can transfer ownership, the owner thread is not a final 
constant anymore... this will probably affect performances considerably

* I haven't even started to look at rejecting overlapping sub regions 
with different owners...

Needless to say, the resulting implementation is very finicky, and I'm 
worried about the overall performance model of this approach.

Also, I don't think that what I'm seeing is an artifact of lumping 
MemoryScope and MemorySegment together - yes, in principle having a 
separate scope (with a notion of confinement in it) helps in the sense 
that resizing a segment becomes an orthogonal concern. But then you are 
back in a world where you can't give a different thread owner to 
different sub-region, and the only way around that restriction is to use 
memory copy (e.g. create a new segment and copy contents of the old one 
to the new).

If that cross-subregion policy is what we realistically want to enforce, 
then I don't think it's worth doing a lot of heroics here - we can 
simply say that a segment is confined to a thread, there's no ownership 
transfer operation, but the same effects can be achieved through memory 
copy. This doesn't seem quite a rich a story as the one we were looking 
at - but if we were ok with Scope being in charge of thread confinement, 
this would have been the only story possible.

So, the question becomes: do we really need a way to transfer ownership 
of a segment from thread A to thread B ? And if so, what granularity 
should be used? I think these are the possible answers:

a) ownership transfer not supported - region copy should be used as a 
workaround
b) ownership transfer supported; all subregion are constrained to have 
same owner as the root; when ownership changes, all subregions change 
ownership too
c) ownership transfer supported; subregion ownership can set 
independently of the root

I realized that, in the email I've sent this morning I picked the most 
difficult point in the design space (c) - that is, support ownership 
transfers at the subregion granularity. This seems useful to implement 
divide and conquer algorithms, but at the same time, I realized, this 
was simply not possible with the scope-based solution we had before 
(since all subregions had same scope there - hence same confinement).

In other words, all the implementation strategies we've seen so far are 
capable of handling either (a) or (b) [as for (b) I'm not sure about the 
potential JIT cost in making thread owner non-final]. The implementation 
story for (c) is far more convoluted (**), and I'm very skeptical that, 
even if we can pull that off, it will perform in a way that will be 
deemed acceptable.

Is (c) simply asking for too much? And, if so, is (b) something that 
could be useful still?

Maurizio

(**) Honestly, the overlapping region check seems the straw that breaks 
the camel's back - to implement the check it's sadly unavoidable to keep 
all subregions which share the same root in the same place - which then 
poses aforementioned problems with respect to such subregions being 
GCed, and need for synchronization when maintaining all the ancillary 
lists. And, this overlapping region check is needed in both the 
approached (1) and (2) that I have outlined earlier in [1], I believe.

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005674.html