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

[Peter Levart]

On Tue, 5 May 2020 10:55:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I agree that the main problem here is the constant acquire/close-ing of memory segment in Spliterator.tryAdvance(). It
>> is interesting to observe a slight performance improvement even in serial stream (according to above results) while the
>> concurrent contention in current MemoryScope is obvious in parallel stream. The above results are of course "distorted"
>> by the fact that there are lots of small elements in the testing stream (int == 4 bytes) so performance figures are
>> dominated by the overhead. But there may be valid compositions of .findAny() or such that use bigger elements so that
>> the overhead plays a minor role. Still, current MemoryScope could present a problem even in such compositions where the
>> alternative MemoryScope would be perfectly acceptable. Anyway I was also thinking of "improving" the Spliterator API
>> with two empty default methods that would present real improvement in such scenarios:  public interface Spliterator<T>
>> {
>>     /**
>>      * Before a sequence of {@link #tryAdvance} calls from a thread, this method may
>>      * be called in the same thread to establish a context that may help in improving the
>>      * efficiency of subsequent {@code tryAdvance} calls. If this method is called and it returns
>>      * normally, then it is guaranteed that the sequence of {@code tryAdvance} calls will be
>>      * followed by a call to {@link #endTryAdvanceSequence} method to end such sequence.
>>      * The end of sequence of {@code tryAdvance} calls may be announced before all elements of
>>      * the Spliterator have been exhausted.
>>      *
>>      * @implNote the default implementation of this method does nothing
>>      * @since 15
>>      */
>>     default void beginTryAdvanceSequence() {
>>     }
>> 
>>     /**
>>      * If {@link #beginTryAdvanceSequence} method is called and the call returns normally before
>>      * a sequence of {@link #tryAdvance} calls, then this method is guaranteed to be called to end such
>>      * sequence and give this Spliterator a chance to clean-up what was established in
>>      * {@code beginTryAdvanceSequence}.
>>      *
>>      * @implNote the default implementation of this method does nothing
>>      * @since 15
>>      */
>>     default void endTryAdvanceSequence() {
>>     }
>> 
>> Would this be an acceptable "addtition" to Spliterator API?
>
>> Would this be an acceptable "addtition" to Spliterator API?
> 
> I'll leave this to Paul. IMHO doing this for an incubating API seems a bit too much (although I can buy that there can
> be other benefits in doing this). Another option would be in having this be a JDK-internal spliterator API, so that our
> own spliterators could implement that and get better stream performances (after all, I don't expect a lot of users to
> come up with their own spliterators). If stream sees that one of those 'special' stream is being used, it can use the
> more efficient implementation.

This would be universally useful. I once already missed such methods in a Spliterator I was trying to design, backed by
database.

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

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