With YANGTOOLS-1001 the math changes a bit, as the paddings are eliminated and NIWP is 24/32 bytes. With 24/32 bytes expended on SharedSingletonMap cost it boils down to a combined overhead of 48/64 bytes.

If we inline the single-predicate case, we will arrive at 32/40 bytes per instance size, with the weird problem of having to deal with the Map return. Ideally this implementation would also implement Map, but that would imply hashCode/equals contract, which we have to set differently. If we disregard hashcode caching for the singleton map, we can be giving out singleton instances on demand – which may or may not work out okay. Alternatively we can bloat a bit, keeping the hashCode for the map inside the NIWP instance (hence growing it to 32/48 bytes) and give out non-static maps which update the hashCode in NIWP.

Looking at the users, it seems the best option is to eliminate the Map return completely, or at least make it an optional secondary interface. Most callers are interested in the keyset/entryset/values and those could be supported without this conundrum. If we structure access correctly, we can also simplify equality contract, as zero-or-multiples would be handled by one class and singletons by another – thus also allowing for reasonable hashCode behavior.

https://git.opendaylight.org/gerrit/#/c/yangtools/+/82604/