[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