[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