RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2]

[Oli Gillespie]

On Mon, 26 Jan 2026 16:01:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failing test
>
> src/java.base/share/classes/java/util/TreeMap.java line 2028:
> 
>> 2026:             }
>> 2027: 
>> 2028:             public abstract Spliterator<Map.Entry<K,V>> spliterator();
> 
> I don't think you need this huge a patch. I think you should just do:
> Suggestion:
> 
>             public Spliterator<Map.Entry<K,V>> spliterator() {
>                 return Spliterators.spliterator(iterator(), Spliterator.DISTINCT);
>             }
> 
> Your patch is introducing spliterator behavioral changes unrelated to the performance regression fix.

Thanks for looking. 

I suppose you mean Spliterators.spliteratorUnknownSize?

Hmm - I made the change this way to be consistent with the existing `SubMapKeyIterator` and `DescendingSubMapKeyIterator`, simply adding the same functionality for the Entry versions. Do you think *those* are overcomplicated too, or there's a reason they're like that that doesn't apply to the Entry versions? I don't know why they were originally added, to be honest, I didn't find much useful context in the history.

I don't know Spliterator well enough to spot any subtle behavioural differences, that's one reason I chose to follow the existing patterns. 

DescendingSubMapEntryIterator is SORTED but SubMapEntryIterator is not, so I'd have to account for that too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733284522