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
