Hi John,
On 2017-12-09 02:20, John Rose wrote:
On Dec 8, 2017, at 4:45 PM, John Rose <john.r.r...@oracle.com
<mailto:john.r.r...@oracle.com>> wrote:
Can anyone point out a reason why the value based
lists of List.of() should serialize while the value based
lists of List.of().subList() should not? Or is there some
reason we should not allow subList to produce value
based lists?
This gets to the heart of a question about how thoroughly we are going
to adopt the concept of value-based. I think we want to accept that a
sub-collection derived from a value-based collection is itself
value-based, whether or not the API point (designed *before* value
based data structures) is supposed to deliver a “view” or not. I.e.,
a view of a value-based collection is indistinguishable from a
non-view, and there are performance costs to maintaining a pretended
distinction, so let’s tune our spec. to avoid those costs.
If I'm right about this, perhaps the most natural way to balance Claes's
design is to add an offset field to ListN, and allow ListN to project
arbitrary
slices out of a backing array.
Then we have only two classes (ListN, List12) even when folks are
slicing all around their lists. That strikes me as (in terms of number
of loaded classes) much more economical than the stuff with a new
bespoke SubList class, with it's own new bespoke iterator class.
And I think the extra int field (in ListN) will melt into the noise.
— John
I think one can interpret the @implSpec in AbstracList::subList to suggest
that the implementation retrieved will subclass AbstractList, which implies
it's *not* Serializable. As we move away from AbstractList then we can of
course choose our own spec, but since it's established behavior I tried as
best I could to retrofit behavior...
As time is likely up for getting this into 10 then I guess we might as well
take a step back and do this right for 11. I suspect we'll need a CSR for
this RFE regardless.
Keeping it all down to two classes as you suggest allows any mixed usage to
stay in the realm of bimorphism which might bring a considerable speedup
in some cases, and the reduction in number of implementation classes
loaded is a boon. Having all methods in ListN account for the offset might
cost us a few percent here and there, though.
An int offset on ListN would actually be footprint neutral compared to the
pre-existing implementation which pulls in the int modCount from
AbstractList.
Thanks!
/Claes
