[foreign-memaccess] RFC: to scope or not to scope?

[Maurizio Cimadamore]

On 04/06/2019 01:04, Jorn Vernee wrote:
> I thought optimization was the whole point of adding the thread 
> confinement... From [1]: 

I might have not expressed myself correctly; the point of confinement in 
critical scope operation is (1) to simplify the user model (giving back 
some determinism on who can do what) and (2) avoid synchronization in 
the innards of the implementation (which can in turn affect hoisting). 
So, while only indirectly related to loop hoisting, this is still 
performance critical business (imagine if every pointer access had to do 
a synchronized access to the liveliness bit).

So, I think confinement of 'close' operation on scope/segment is really 
the most basic requirement to get a relatively fast implementation.


Then there's confinement on the entire region access (which has been the 
subject of the discussions in this thread) - which I can see as being 
useful in some cases, but I can't quite feel as strongly as you do in 
mandating it.

Personally, I view the 'asConfined' operation more as a super-user 
operation that's useful to who creates the segment in the first place. 
Example:

* master thread T_M create a big segment

* slice it into many sub-segments Si, and mark each confined to thread Ti

* thread Ti will work on Si, and cannot interfere with work of any other 
thread/segments

* eventually, all workers thread Ti complete and T_M does something to 
evaluate the results (since they are all in the big segment now)

Since each thread is handed over a confined segment, they are the only 
one with access to that particular subregion. But note, that the master 
region these subregion come from is not confined - in fact all these 
thread can write _all at the same time_ w/o any need for synchronization 
(as they are operating on disjoint regions).

My point is that patterns such as these will almost _always_ require 
some kind of well-thought co-operation between the parties involved. And 
to me, the important bit is that we make sure that we can express 
patterns such as this one w/o incurring in (too much) extra costs. I'm 
less worried about a malicious worker thread that tries to steal the 
non-confined master region from the master thread just to mess things 
up. Besides, the Java language should offer enough encapsulation 
strategies to make this hard enough.

In other words, it was never the intent of 'asConfined' to take an 
arbitrary segment, and turn it into a confined-only view that would 
render other operations on the same region invalid. It is a tool in the 
toolbox which, if applied correctly, can be used to hand over confined 
(sub)segments to different clients.

The 'confinement' of memory access will always be a 'fiction' of some 
sort - there will be cases, such as for segments coming from 
heap-allocated objects where confinement is very hard to enforce (in 
addition to 'disabling' access to the master segment - how do we exactly 
disable access to the e.g. underlying heap allocated array?). This has 
sent me into the path of treating 'asConfined' as a privileged operation 
invoked by the piece of code that is responsible for setting up the segment.

But really, if the treatment of 'asConfined' I describe here doesn't 
seem satisfactory, then I really can't see why 'asReadOnly' seems more 
palatable, since they both share the same underlying issue (e.g. there's 
some master region which is neither read-only nor confined, which code 
could go to some length to try and get their hands into).

Having heard the objections, I think I'm still pretty happy with 
asReadOnly() and asConfined(). Users of these methods will have to know 
what they are doing, but that's the case with this API in general.

A fallback position I could live with, is to remove the 'asXYZ' methods, 
and turn them into construction parameters (that is, eliminate all views 
- but sub-segments). That would mean adding extra parameters to all the 
factories and also to the 'resize' method. But I guess I failed so far 
to see the 'killer argument' against the asXYZ views.

Maurizio