[PATCH] Inefficient ArrayList.subList().toArray()
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