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

Paul Sandoz psandoz at openjdk.java.net
Wed May 6 16:36:41 UTC 2020

On Wed, 6 May 2020 16:01:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>>   Re-add fullFence() in MemorySegment.withOwnerThread() due to effect on the segment backing memory which is not
>>   guaranteed by JMM otherwise
> The code looks good - leaning towards approving and see how it goes.
> One thing I noted is that there are many assumptions that some methods can only be called from owner thread - but while
> that's true for the 'safe' API, that's not the case for the unsafe API; in that case I have a vague feeling that the
> old atomic would behave a bit more predictably.

Thanks Peter for the explanation.  I now see why two monotonically increasing counters work (with careful ordering the
non-atomic sums).  My sense is we should let this soak in the panama repo.

With regards to the proposed changes to `Spliterator`, i fear this will complicate the already complicated set of
interactions that are possible, and require clients to take into account what is in effect a new characteristic.
Instead i am wondering if we can add a new traversal method that can short-circuit, for example:

    // traverses until no elements or the action returns false, which ever is first
    // if action returns false and if there are elements remaining then traversing may continue
    // with further calls to this method, or tryAdvance, or forEachRemaining
    default void forEachSomeRemaining(Predicate<? super T> action) {
        boolean[] _continue = new boolean[1]; // ugly side return
        boolean continue;
        do {
            boolean continue = tryAdvance(e -> { _continue[0] = action.test(e); });
        } while (continue && _continue[0]);


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

More information about the panama-dev mailing list