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

[Oli Gillespie]

On Tue, 27 Jan 2026 18:39:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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.
>
>> I suppose you mean Spliterators.spliteratorUnknownSize?
> 
> Yes. Thanks for corecting me.
> 
>> 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.
> 
> I made the recommendation given the starting point is to address a performance regression, instead of to enhance the sub-map entry spliterator to be on par with the `DescendingSubMapKeyIterator`.
> 
> From this starting point, I believe we can easily identify `EntrySetView` inherits `Set::spliterator` which is slow because the spliterator calls `size()` frequently. This root problem is easily fixed with using `Spliterators.spliteratorUnknownSize`, which also has the minimal behavioral impact.
> 
> In contrast, functional enhancement to spliterators is really a can of worms where you can never find an end - sometimes you add more flags, sometimes other splitting strategies. And in your example, you already have a test case failing due to the functional enhancements while you did make new tests to verify them.
> 
> So let's keep it simple, fix the bug, and leave the functional enhancements for another time. This also makes backporting the fix much easier.

Okay sounds good to me! Thanks for the suggestion, I'll update later this week.

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

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