[Ecls-list] allocation, GC, explicit destruction and finalizers

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Tue Feb 8 22:17:04 UTC 2011


On Tue, Feb 8, 2011 at 10:55 PM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> - Memory custom-allocated using ecl_alloc() or ecl_alloc_align() in
>  C-inline code will automatically get garbage collected if no longer
>  referenced
>

True.


> - If a finalizer is wanted at GC collect/destruction time,
>  si_set_finalizer() can be called with the cl_object of the foreign
>  pointer and the cl_object of a custom finalizer function which will
>  be called by the GC before such memory is reclaimed
>

Also true.


>  - If wanted, ecl_delloc() may be used to haste destruction of an
>  allocated object, and any custom registered finalizer will also
>  automatically/implicitely be called
>

No. Various things.

The first one is that finalizers are not immediately called during garbage
collection. That would be insane, because arbitrary lisp code can only be
invoked when memory allocation is possible. Instead, a garbage collection
may trigger a finalization process which first revives the object, then,
possibly in the next GC cycle, finalizes it and finally, being zeroed
memory, it gets deallocated.

Second, ecl_dealloc() is just a hint to the garbage collector. Memory may or
may not be marked as unused immediately, but even then, finalization will
not be called until the GC cycle process I mentioned before happens. In
general this is true for all garbage collectors: finalization is associated
to GC not to "deallocation", an operation which is too costly if carried on
fully.

So if you want deterministic finalization, first finalize the object and
_then_ deallocate it.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110208/acfd6508/attachment.html>


More information about the ecl-devel mailing list