RFR(s): 8203670: unmodifiable List iterator() implementations should not be ListIterators

[Claes Redestad]

On 2018-06-26 19:51, Stuart Marks wrote:
> Peter Levart wrote:
>
>> Also, performance would be better if it was a separate class. It 
>> could be a superclass of ListItr so that common logic is not duplicated.
>
> This isn't at all obvious. Certainly it's not obvious enough to embark 
> on a refactoring without doing some benchmarking.
>
> However, I want to fix this bug in JDK 11. If somebody wants to do 
> some benchmarking, they're welcome to do so, but I don't want to 
> consider this as part of this changeset.

I don't have time to do any benchmarking here, sorry, but could 
counter-speculate that the tests are likely to be eliminated by the JIT 
anyway, and that keeping only one implementation class might allow some 
hypothetical callsite to stay mono- or bimorphic that would otherwise 
become bi- or megamorphic. So yes, it's not obvious that splitting will 
improve performance.

>
>> @Stable annotation on private final boolean isListIterator does not 
>> help here unless the returned Iterator object is assigned to a static 
>> final field and used from it. Hardly a common use case for 
>> Iterator(s) I guess.
>
> The exact effect of @Stable is Hotspot-specific and changes over time. 
> Here we're using it as a declaration that this final field really can 
> be treated as final, and that it won't be modified via reflection or a 
> varhandle, thus enabling VM more aggressive optimizations.

+1, even though I suspect Peter is right for now. :-)

The patch at hand looks good to me as-is.

Thanks!

/Claes