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

John Rose john.r.rose at oracle.com
Sat Dec 9 03:00:42 UTC 2017

On Dec 8, 2017, at 6:19 PM, Claes Redestad <claes.redestad at oracle.com> wrote:

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…

Maybe you are right about that, but AbstractList is not part of the API of the List returned by List.of, so you are free to do whatever is right for the value-based list, ignoring all parts of AbstractList that are not immediately valuable to you.

(Yes, someone could "notice" that the result of List.of seems to be castable to AbstractList, and then lodge a complaint that its sublist is serializable, but that's a forced scenario; if we deem it is a real bug to fix, at some date far in the future, we can fix it by removing AbstractList from the supers of the List.of result.)

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.

No, we don't need a CSR. It's unspecified behavior. And in a brand new API. This is a valid refinement from murky to clear, not a change in spec. (Because it's brand new, there's not even a de facto spec. to worry about.)

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.

I don't think it will. It's a fetch of an addend (usually zero) from a cache line that is already hot. Hot fetches and extra addends are usually in the noise.

An int offset on ListN would actually be footprint neutral compared to the pre-existing implementation which pulls in the int modCount from AbstractList.

Yep. And it will be an improvement to the number of classes loaded, both in the status quo and in your current version (with bespoke sublists and their iterators).

— John

P.S. The extra cut-n-paste of the helper classes was bothering me, enough to consider asking for new API points for sublist views. But if you do the ListN with an offset, those problems can be pushed off for another day.

More information about the core-libs-dev mailing list