Hi Roland,
Because of the aforementioned memory consumption, we will want to do
early finalization during the first copying walk whenever possible.
That is, do the "second walk" work for any subtree that has no
references to other entries that are not yet final.
Is that all clear? I'm not sure it's entirely necessary wrap one's
head
around all the hairy bookkeeping of the current plan. The new plan is
replacing it with something easier to understand anyway.
Yes, things are more clear now. Thanks. And dropping the pending_entry
asap to safe memory also makes sense. But is the state held separately
in pending_entry really that much and/or can't it just be derived from
entry itself? It is somewhat hard to change the hairy bookkeeping without
understanding how it currently works.
The reason I am looking at this is indeed to see if it can be simplified.
If I am looking at this right then if we move the dwarf_output
attribute_map held in pending_entry to entry, and we derive
the children from the identities held in the _m_entries map, then it seems
we have all needed state. But I might be missing some of the other purposes
of pending_entry like the usage in pending_dwarf comparator. See below.
There will still be some hairy magic for cases of circular
references.
An entry can't be truly final until all its references are final, and
thus that's a circular requirement. That's why we need the "placed"
stage, where a value_reference already in the collector gets reified
with the actual iterator into its referent's parent's children vector.
As far as I understand the circular references are constructed to be
used in the pending_dwarf comparison. Again, I am hoping we can get rid of
that and do the comparison on the original input die tree when we need to
compare two entries (since we do/should have the references to the original
tree for both and if attributes are similar in the original trees, they
should be equal in the newly constructed dwarf_output tree), instead of
doing them on the pending tree (and again I might be missing why that is
impossible).
Cheers,
Mark