[PATCH] Inefficient ArrayList.subList().toArray() (original) (raw)

John Rose john.r.rose at oracle.com
Tue Jan 30 00:00:59 UTC 2018


Reviewed (officially). This is a good point-fix.

— John

P.S. I still think we have some tech. debt to discharge in finding a way to generically provide zero-copy access to array data, across interoperating collections APIs.

If we got the deeper, more general answer right, we would be able to reformulate the present point-fix in terms of a single viewing operation, and then apply it in other places (like Arrays.asList) without more code duplication.

I think (though am not sure yet) that the Collection::stream API point is the right place to inject zero-copy array viewing capabilities. A specialized array-backed Stream (SIZED, of course) would provide a general but efficient connection point, that would allow private arrays to be securely read but not written. Then the various array-backed implementations (and their sublists) would simply override their respective stream views. The copyOfRange step would appear, not in a bunch of point fixes, but centrally in the array-backed stream code. A package-private class could mediate secret access to the backing array, if necessary.

See also this discussion about generic array-producing terminal methods, near this message: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050560.html

On Jan 29, 2018, at 3:30 PM, Martin Buchholz <martinrb at google.com> wrote:

On Mon, Jan 29, 2018 at 3:10 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote: > On Jan 29, 2018, at 1:02 PM, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote: > > I'm going to expedite this a little since we are building further changes > on top. > > RFR: jsr166 jdk integration 2018-02 > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html <http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html> > Looks ok, but i personally would not categorize the F/J changes as miscellaneous :-) Sorry, we're still working on forkjoin; only the ArrayList changes are ready to go.



More information about the core-libs-dev mailing list