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

[Jorn Vernee]

Thanks John, I think I understand the problem. Another idea that comes 
to mind is to have threads register themselves with the shared segment 
and then have a mechanism to forcibly commit writes when one thread 
wants to acquire confinement. Similarly for reads we'd need a way to 
'clear the cache' for all registered threads when a segment is released 
from confinement again, so that no stale data is read. But the shared 
state would just be a racy anarchy. Your idea of not allowing 
reads/writes in the shared state seems to give much nicer/stronger 
guarantees.

But, currently I think we just want to make the terminal operations 
confined, so that we can hoist liveliness checks out of loops. I have 
been thinking about this some more and realized that the thread 
confinement solution also relies on the loop body being inlined (or at 
least not having opaque sinks that could close the segment out of our 
view). I think my idea of having a temporary local copy of the segment 
'control block' actually solves the same problem. Since the liveliness 
flag is local to the method (if used correctly), it's also confined to 
the executing thread.

Later on we could add Queued <-> Confined variants of MemorySegment that 
are geared towards confinement of the actual memory resource.

Jorn

John Rose schreef op 2019-06-02 05:45:
> On Jun 1, 2019, at 8:41 PM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>> For example, if the root segment allows writing, then any thread can
>> initiate a racy write to it.  Unless this is provably under a mutex of
>> some sort, this racy write can still be "handing around" when the
>> segment transitions back to the confined state.  This means that the
>> confined state can suffer "hangovers" from previous states, when a
>> write from that state is not yet completed.
> 
> (I meant to say "hanging around".  If you read the JMM carefully
> you will be horrified to find that there are no promptness guarantees
> about reads and writes, unless they are also connected with
> monitors or volatile references.  Java platforms tend to commit
> writes quickly, whatever that means, and report reads from fresh
> data, whatever that means, but this is *not* guaranteed by the JMM.)