[foreign-memaccess] on confinement

[Maurizio Cimadamore]

On 05/06/2019 21:30, Maurizio Cimadamore wrote:
> So... what if:
>
> * you always needed a scope to create a segment, regardless of the 
> kind (e.g. the segment factories will get a scope parameter)
>
> * we have two scopes: shared and unshared - shared scope supports 
> handoff, the unshared doesn't (and, if we have public types we can 
> make that explicit)
>
> * handoff/close operations goes in the scope
>
> * we have a MemorySegment interface, but also a MemorySubSegment 
> interface which supports an extra 'merge' operation
>
> I think this could work - and seems more orthogonal than what we were 
> trying to do before? 

After sending this, I realized that this approach doesn't really support 
all the use cases we've talked about.

The fundamental issue is still one of granularity. We've been trying to 
take a region, slice it up into multiple segments, and then have each 
segment handed to a different thread.

In a model where regions are created within scopes, it stands to reason 
that, if you slice a region, you keep the same scope as before (and the 
same owner associated with the scope).

If handoff is a scope-wide operation, rather than a region-wide one, 
then it's not possible to hand over single (sub)regions to separate 
scopes/threads; the only thing you can do is to hand off a scope to a 
different owner, but that will de facto transfer ownership of all 
regions created within that scope. And, worse, the regions will just 
become unusable if the handoff operation is stateless like the one that 
we were discussing earlier.

On a deeper level, we also know that, at some point we want to introduce 
some form of temporal bounds - e.g. to be able to prove that the 
temporal extent of a region is bigger/smaller than that of another 
region. This is done, currently, via the parent/child relationship in 
MemoryScope. The danger I see in some of the things we have been 
discussing, is that we effectively have _two_ dimensions along with 
regions can be compared:

* spatial - a subregion is contained into a bigger region
* temporal - a region lifecycle is contained by that of another region

I think this is close to a deadly mix - we know how to reason about 
these two dimensions separately, but when you start mixing them both _in 
the same API_, things spiral out of control pretty quickly, and the 
resulting user model is very complex to explain to a developer (even an 
experienced one), as there are just too many variables. This also 
creates a possible potential for performance cliffs, since each cell in 
the matrix of all possible combination between the possible flavors is 
likely to have a different point in the performance space.

I think it's time to take a step backwards and look back at the 
requirements and use cases we want to support for this API, and see how 
we might best get there. I'll do some more (hard) thinking on this, as 
it doesn't feel like we're out of the woods quite yet (but the 
discussions has been very useful in understanding all the various 
constraints we're trying to balance at the same time, so thanks!).

Maurizio