Object creation from iterating Map.of()/Set.of()/List.of()

[-]

Also see https://github.com/openjdk/jdk/pull/15614, which removes caching
in `AbstractMap` etc, meaning once Valhalla is out, the anonymous set will
be a value object with no overhead. In addition, hotspot already has an
escape analysis mechanism which can optimize iterators to index for loops
if it determines an iterator does not get shared.

On Fri, Feb 2, 2024 at 2:54 PM Jason Mehrens <jason_mehrens at hotmail.com>
wrote:

> See: https://bugs.openjdk.org/browse/JDK-8193128
>
> Jason
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Ryan
> Ernst <ryan at iernst.net>
> *Sent:* Friday, February 2, 2024 1:42 PM
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Object creation from iterating Map.of()/Set.of()/List.of()
>
> The newer “of” methods in collections are really nice, they make creating
> these collections much easier and often result in better performance.
> However, the empty collection cases with Map.of()/Set.of()/List.of() has
> one small downside. The implementations within ImmutableCollections use
> non-specialized implementations for zero sized collections. For example,
> ImmutableCollections.EMPTY_MAP is a MapN. If you iterate over that Map,
> even if it is empty as in the case for Map.of(), a new anonymous
> AbstractSet is created. In comparison, Collections.emptyMap().entrySet()
> returns emptySet().
>
> I don’t know what the reasoning was for rebuilding the empty based
> variants in ImmutableCollections. But regardless, it seems like the empty
> collections defined in ImmutableCollections should likewise never construct
> any objects.
>
> I’m happy to raise a PR to either mimic or reuse the empty collection
> implementations from Collections, but I wanted to check there isn’t some
> reasoning the of() methods work this way.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240202/17420558/attachment.htm>