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

Maurizio Cimadamore mcimadamore at openjdk.java.net
Wed May 6 10:39:23 UTC 2020

On Tue, 5 May 2020 18:02:27 GMT, Peter Levart <plevart at openjdk.org> wrote:

> 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.


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

More information about the panama-dev mailing list