RFC-24 Mapscript memory management: call for comments

[Tamas Szekeres]

2007/1/19, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> Tamas,
> I am afraid this might not work. Consider this for example:
>
> 1) in function 'a' a new mapObj is allocated
> 2) the mapObj is passed to function 'b' which allocates a new layer
> and adds it to the map. The new layer is a local variable, suitable
> for gc after method 'b' returns
>
> at step 1 the mapObj has refcount=1, after step 2 the layerObj has
> refcount=2 (1 for itself and 1 from the map).
>
> When function 'b' returns the gc deletes the layer object. The
> destructor will not deallocate memory because (--refcount>0) evaluates
> to false.
> The map object will also not release this memory because every object
> is responsible for itself, but the object responsible for the layer
> memory has already been GC'ed.
>

You are possibly thinking of a following pattern at the target language:

1.   mapObj map = new mapObj();
2.   layerObj layer = CreateNewLayerAndAddToTheMap(map);

At the C side of the code, when adding the layerObj to the mapObj (the
parent-child relationship is established) the refcount of the layer is
incremented (or set to 1 for a newly created layer) so as to keep the
lifespan of the child at least as long as the lifespan of the parent.
Later on when the parent is destroyed the destroy function (eg.
msFreeMap) will internally call the destroy function of the child (eg.
freeLayer) to decrement this reference, so this case should work.

My previous 'every object is self-owned' statement has applied to the
wrappers at the target language not to the structures at the C side.


> I would go as far as stating that reference counting will NEVER work.
> In fact the only language that still uses a main gc based on reference
> counting is Perl and it is explicitly said in the docs that it might
> create memory leaks when there are cyclic references.
> To be fair Perl also has another gc that can detect these leaks, but
> it kicks in only when a thread ends or the vm exits.
>

I would not be so radical. The reference counting approach is
currently used in may areas (like. with the COM object implentation).
Certainly there are some rules to follow to avoid the circular
references, but I'm sure in this case it can be handled at the C side
of the code. Apperently, the object hierarchy is established in a
controlled manner that cannot be violated from the scripting interface
side.

For example to avoid such problems, when adding the child to the
parent and setting the back-reference at the child to the parent,  the
refcount of the parent would not be incremented. This pointer would be
set to null when the relationship is cleared (removing the layerObj
from the mapObj).

In exchange for some additional complexity all of the raised issues
could be handled uniquely. Furthermore, there are further
possibilities like one child could even belong to multiple parents.

Best Regards,

Tamas