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-1074 yangtools <p>Analysis of a netvirt heap dump is showing that the data tree involved is around 640MiB, with 147MiB (~23%) retained by NormalizedNode implementations (6.5M objects). Each of these is costing typically 24 bytes, with 4 byte alignment shadow - typically containing the identifier and map of children.</p> <p>If we eliminate the idea that a NormalizedNode has an identifier, we would save ~49MiB (33% shallow, 13% overall) heap by making these cost typically 16 bytes.</p> <p>There are few places where identifier is required, which would have to be changed to carry Map.Entry&lt;PathArgument, NormalizedNode&gt; instead - a change cascading through quite a few interfaces. The most problematic will probably be NormalizedNodeStreamWriter.</p> <p>Aside from memory savings, this would solve the interesting problem of DataTree root node (i.e. corresponding to SchemaContext) needing an identifier, which is currently wedged to use SchemaContext.NAME - which can lead to problems with revisions in some cases.</p> <p>Consider dropping Identifiable from NormalizedNode, adjusting all users to cope with that.</p> YANGTOOLS-1074

Define NormalizedBody and specializations

Improvement High Confirmed Unresolved Unassigned Robert Varga Wed, 22 Jan 2020 09:25:23 +0000 Tue, 19 Sep 2023 16:19:44 +0000 14.0.0 data-impl 0 1 <p>The idea is to have:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">public</span> <span class="code-keyword">interface</span> ContainerNode <span class="code-keyword">extends</span> Map.Entry&lt;NodeIdentifier, ContainerNodeState&gt; [ <span class="code-keyword">extends</span> SchemaNode state mess], Identifiable&lt;NodeIdentifier&gt;, ContainerNodeState { <span class="code-keyword">default</span> NodeIdentifier getIdentifier() { <span class="code-keyword">return</span> getKey(); } } <span class="code-keyword">public</span> <span class="code-keyword">class </span>DefaultContainerNode <span class="code-keyword">extends</span> AbstractMap.ImmutableSimpleEntry&lt;NodeIdentifier, ContainerNodeState&gt; <span class="code-keyword">implements</span> ContainerNode { } </pre> </div></div> <p>which would be a compat view. Except naming sucks – is much better to not lug around "State" suffix in most places. It also has performance implications on streaming API, where we really want to propagate these from a Map.entrySet(), otherwise we could end up hurting the GC.</p> <p>I do not believe we can deliver this in Aluminium.</p> <p> </p> <p>The entry part of this proposal needs to be provided separately, as it would end up propagating type. The idea is that NormalizedNode is <b>semantically</b> equivalent to Entry&lt;PathArgument, ? extends Object&gt;, but we do not express that as a generic parameter by rather through an</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> NormalizedNode { <span class="code-keyword">default</span> Entry&lt;? <span class="code-keyword">extends</span> PathArgument, ? <span class="code-keyword">extends</span> <span class="code-object">Object</span>&gt; toEntry() { <span class="code-keyword">return</span> Map.entry(getIdentifier(), body()); } } </pre> </div></div> <p>We then override this method to provide more precise approcimation, so that:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> ContainerNode <span class="code-keyword">extends</span> NormalizedNode { @Override NodeIdentifier getIdentifier(); @Override ContainerBody body() @Override <span class="code-keyword">default</span> Entry&lt;NodeIdentifier, ContainerBody&gt; toEntry() { <span class="code-keyword">return</span> Map.entry(getIdentifier(), body()); } } </pre> </div></div> <p>We need the equivalent of ContainerBody for every NormalizedNode so that nodes can reconstructed easily. ForeignDataNodes are an exception: their body is a foreign representation, which we know nothing about (it can be a DOMSource).</p> <p>There is an interesting conflict between LeafNode and AnydataNode: how do we know an AnydataNode is not represented as a byte[], which is the same as a leaf for 'type binary'.<br/> It seems this issue is a bit more thorny: we certainly want to solve ContainerNode (due to identifier) and LeafNode/LeafSetEntryNode (for memory efficiency), but others perhaps can be left alone for later.</p> <p>If we scope out those two, they boil down to:</p> <ul class="alternate" type="square"> <li>ValueNode, which covers LeafNode and LeafSetEntryNode. When dealing with reconstitution, LeafSetEntryNode can be known to be allowed only in LeafSetNodes and LeafNode is a DataContainerChild which implies its parent is a DataContainerNode</li> <li>ContainerNode is a DataContainerNode (and DataContainerChild which adds guidance from ValueNode)</li> </ul> <p>Looking at DataContainerNode, it is a DistinctNodeContainer (implying child addressability) and has three specializations:</p> <ul class="alternate" type="square"> <li>ContainerNode</li> <li>LeafSetNode (note: addressability is wild &#8211; either linear position for ordered, or identifier for unordered, this is still subject to evolution)</li> <li>MapNode (addressability, but shares ordering w.r.t. UserMapNode/UserLeafSetNode)</li> </ul> <p>DataContainerNode itself covers AugmentatioNode (which is going away) and ChoiceNode, ContainerNode, MapEntryNode, MountPointNode<img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/warning.png" height="16" width="16" align="absmiddle" alt="" border="0"/>, UnkeyedListEntryNode &#8211; not all of which reap the memory benefits.</p> Development Epic Link YANGTOOLS-1022 Rank 0|i03qwf: