On Wed, 25 Nov 2020 17:14:43 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> An alternative with similar performance would be to do a Stream.toArray() >> and then copy that array into new Object[] and then wrap that copy with >> listFromTrustedArrayNullsAllowed(). The difference would be in the >> serialization format of the resulting List and maybe also in the access >> performance of resulting List (no indirection via the unmodifiableList >> wrapper and different type for JIT to speculate about). So if we want the >> resulting List to behave exactly the same in both implementations of >> toList(), then this alternative might be preferable. WDYT? > > Such alternative might also be faster using intrisified array copying method > (here measuring just copying overhead): > > Benchmark (len) Mode Cnt Score Error Units > ToListBench.toList1 10 avgt 10 14.213 ± 0.061 ns/op > ToListBench.toList1 1000 avgt 10 541.883 ± 3.845 ns/op > ToListBench.toList1 1000000 avgt 10 753223.523 ± 4656.664 ns/op > ToListBench.toList2 10 avgt 10 8.810 ± 0.052 ns/op > ToListBench.toList2 1000 avgt 10 264.748 ± 0.807 ns/op > ToListBench.toList2 1000000 avgt 10 349518.502 ± 3242.061 ns/op > > https://gist.github.com/plevart/974b67b65210f8dd122773f481c0a603 I don't want to change the default implementation and its specification, for a couple reasons. First, this implementation won't be used in normal operation, as it's overridden by the JDK implementation. (I expect that stream extension libraries will be updated to override it as well.) Second, I'm quite uncomfortable using an internal method from within a default implementation. Right now this method is an agreement between the unmodifiable collections implementation and the ReferencePipeline implementation, and we have complete freedom to change this agreement at any time. If this internal method were used from a default implementation, its behavior would have to be specified in `@implSpec` somehow. Certainly one could write some very vague words for the specification that allow some freedom to make changes, but this has to choose between a better specification and more implementation freedom. I don't see the value in having to make this tradeoff at all. An extra copy can be avoided via a private agreement between ArrayList and Arrays.asList, which should probably be done in any case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1026
