Re: [gdome]future memory management plans? (was: News(2) on CVS preparing 0.7.0)

[Tobias Peters <t-peters gmx de>]

On Fri, 9 Nov 2001, Paolo Casarini wrote:
> The idea is to use the Gdome_xml_Node.refcnt, the xmlNode.parent and the
> xmlNode._private fields to understand if a Node and the subtree under
> it is to be freed on unref.
>
> The n->parent field of a root node of a detached subtree is NULL, so when
> the user call unref on such node and its refcnt reach 0 we can free its
> xmlNode structure.
>
> We need n->_private to know which node of the subtree are to be freed:
>
> Example: suppose to have the follow detached subtree where the node A and
> C are referenced each by one GdomeNode*.
>
> <A>        //referenced
>   <B>
>     <C>    //referenced
>       <D/>
>     </C>
>   </B>
>   <E/>
> </A>
>
> When the user call unref on A we can free A, B and E libxml2 underling

Sorry, but you can't. The application could use its reference to C to
access B (Node::parentNode), and recursively A and E. Just because there
is no current reference to A does not mean the application does not want
to create one in future.

Detached subtrees can only be freed completely. The only choice I see that
you have is this:

(1) you can free the tree right then when the last reference to it is
    going away.
    Without a tree-level memory management this would involve a traversal
    of the whole subtree until a referenced node is found (or none is
    found).
    The performance of this aproach is probably really bad.
(2) free all subtrees only when the whole document is freed. Then you have
    to keep track of detached subtree roots on the document level. This
    would be possible since each subtree detachment / merger is a dom
    operation.
    Memory might fill up in very special cases where a single document is
    heavily edited, but no one could call this a memory leak, since all
    memory will be freed again.
(3) tree-level memory management. But this is not an option with the
    current codebase.

> structures while C and D are taken live by the C reference. When the user
> call unref also on C, we can also free C and D underling libxml2
> structures.

Bye, Tobias