[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

[Claes Redestad]

Hi John,

On 2017-12-09 02:20, John Rose wrote:
> On Dec 8, 2017, at 4:45 PM, John Rose <john.r.rose at oracle.com 
> <mailto:john.r.rose at 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