https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-999 yangtools <p>Heap dump analysis from <a href="https://jira.opendaylight.org/browse/CONTROLLER-1898" title="Improve NormalizedNodeData{Input,Output} QName coding" class="issue-link" data-issue-key="CONTROLLER-1898"><del>CONTROLLER-1898</del></a> shows that a typical openflow-related workload does not use more than one predicates anywhere – every one of the 1.4M objects has exactly one predicate.</p> <p>This translates to 1.4M SharedSingletonMap instances, each costing a 24 bytes of storage – for a total of 34MiB, i.e. 3.7% of total memory footprint.</p> <p>Current layout of NodeIdentifierWithPredicates results in 32/40 bytes per instance, with 7 bytes being wasted on alignment – hence we could inline the single key/value eliminating the need for retained secondary objects.</p> <p>While straightforward, this will result in a Map, which will not retain a cached hashCode, hence is subject to trade-offs and further design.</p> <p>Irrespective of that, we need to turn this class into a non-final value-based object, i.e. eliminate all of its public constructors, so that users are no longer strongly connected to its design.</p> <p> </p> YANGTOOLS-999

Rework NodeIdentifierWithPredicates

Improvement Medium Resolved Done Robert Varga Robert Varga Thu, 30 May 2019 13:18:44 +0000 Sun, 10 Apr 2022 18:36:03 +0000 Tue, 3 Sep 2019 18:38:00 +0000 4.0.0 0 1 <p>With <a href="https://jira.opendaylight.org/browse/YANGTOOLS-1001" title="Reconsider AbstractPathArgument hashCode()" class="issue-link" data-issue-key="YANGTOOLS-1001"><del>YANGTOOLS-1001</del></a> 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.</p> <p>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.</p> <p>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.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/yangtools/+/82604/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/yangtools/+/82604/</a></p> YANGTOOLS-1000 Development Rank 0|i03o1j: