Avoid wasted memory on empty maps and sets

[Dunemaster]

Empty LinkedHashMaps waste quite a lot of memory (250kb) for a medium size project

The PR introduces a simple fix

A screen from yourkit profiler:

[jhoeller]

Any specific reason to use Set/Map.of() over Collections.emptySet/Map()? The latter seems even more efficient implementation-wise.

[Dunemaster]

Any specific reason to use Set/Map.of() over Collections.emptySet/Map()? The latter seems even more efficient implementation-wise.

Would you be so kind to explain the difference? Both methods return a static instance of an empty map/set.

I used Set/Map.of() for the sake of brevity, and do not see any performance benefit in using either Set/Map.of() or Collections.emptySet/Map()

[vlsi]

The difference between Map.of and Collections.emptyMap is that Map.of().contains(null) would throw exception while Collections.emptyMap().contains(null) would return false.

See https://stackoverflow.com/a/46406203/1261287

[Dunemaster]

The difference between Map.of and Collections.emptyMap is that Map.of().contains(null) would throw exception while Collections.emptyMap().contains(null) would return false.

See https://stackoverflow.com/a/46406203/1261287

wow, thanks.
I will change to Collections.emptyMap, if you think that is better

[jhoeller]

Aside from the contains(null) benefit, the footprint of Collections.emptySet/Map() should also be slightly better since those implementations are actually designed for emptiness (not just initialized without any elements as with Set/Map.of()).

[vlsi]

Can you elaborate?

AFAIK Map.of returns a static instance that is optimised for empty case: https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/java/util/Map.java#L1333

[Dunemaster]

Replaced Set.of() and Map.of with Collections.emptyXXX in order to avoid possible compatibility breaks

[vlsi]

LGTM, thanks.

Frankly speaking, I incline that adding early return in checkConfigMembers would make the code slightly easier to follow.

[mjd507]

Looks good for me (I’m just not quite sure about the impact of the code changes from high level, so let someone else to review and approve)

[sbrannen]

This has been merged into main in 3738a45 and revised in d5fb5d0.

Thanks

[Dunemaster]

Should this change be ported to 5.3?

[sbrannen]

Should this change be ported to 5.3?

We do not intend to backport minor enhancements such as this to 5.3.x.