[foreign-memaccess] [Rev 02] RFR: Alternative scalable MemoryScope

[Peter Levart]

On Wed, 6 May 2020 10:36:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ah, I see. Will revert that back then. But why is AbstractMemorySegmentImpl.withOwnerThread() doing this differently
>> than AbstractMemorySegmentImpl.acquire() ? acquire() too is handing access to a different thread and in acquire() there
>> is no explicit fence.
>
>> But why is AbstractMemorySegmentImpl.withOwnerThread() doing this differently than AbstractMemorySegmentImpl.acquire()
>> ? acquire() too is handing access to a different thread and in acquire() there is no explicit fence.
> 
> This is a valid point. I guess from the past, acquire() meant "racy" - whereas for handoff patterns (e.g.
> withOwnerAccess) we wanted to be extra careful that only one thread at a time has access.
> Note that, currently, while all acquired segments slices can be operated concurrently in a race-free fashion,
> unfortunately there is still the main segment that can be written/read concurrently by the original thread. So adding
> fences in this situation just kicks the can down the road.  If we had a way so that the original segment became
> inaccessible while splitted with a spliterator, then I'd agree with you that a fence would be ideal (since this is
> another case of handoff).  But it is very hard to invalidate the original segment; few options I've considered:
> 
> * make the 'valid state' check more complex - e.g. in your implementation we could check whether the two counters yield
>   same value before allowing access to the original thread - but I think this would be slow, and I think it could still
>   allow races (this is a case of check & act - where we have no guarantees that, by the time memory is read/written, the
>   condition we checked still holds true)
> 
> * as we do in other places of the API - just kill the original segment after you split (e.g. make it not alive). This
>   will make it inaccessible, which is consistent with what we want. But now there's a problem: how do you get back the
>   original segment after you're done with the spliterator? Joining slices is messy. And add synchronization to allow for
>   spliterators to be 'closed' atomically, will just add more contention.
> 
> So, it seems like the cost for fixing this particular issue is higher than the actual problem; there's an access mode
> called ACQUIRE - if a segment owner is not OK with having races with different threads - that mode can be disabled.

Yeah, I was just thinking of the situation where a segment is passed to parallel stream and the threads of parallel
stream operate on slices (acquired children) in read-only way, since this is the source of information and should not
be mutated. Now if the segment was created and written to in one thread before handed to parallel stream then workers
from the FJPool may not see the content of their slices (acquired children) fully initialized since normal
synchronization like dispatch of control to other thread presumably doesn't have the same effect on the off-heap memory
(on all platforms)?

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/142