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

Claes Redestad claes.redestad at oracle.com
Sat Dec 9 02:19:13 UTC 2017

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

More information about the core-libs-dev mailing list