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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
