[Ecls-list] ECL 10.3.1 GC finalization bug and patch

Ram Krishnan kriyative at gmail.com
Sun Mar 21 17:23:33 UTC 2010


On Sat, Mar 20, 2010 at 7:49 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> I have done some further investigation and your code works with ECL as of
> git/CVS.

That's great. Thanks.

> First of all I removed the finalization queue in ECL, as it seems that newer
> versions of the collector invoke the finalizers in a safe environment.

Yes, this was why I was failing to understand the motivation behind
queueing_finalizer(). It makes sense put in historical context.

> Note that I replaced your printf() with a FORMAT. No problem here. Second,
> finalization is not guaranteed to happen when you call SI:GC because the
> garbage collector may still have references to the objects. In this case
> even though the functions and code that create the variables have exited,
> there may be dangling references in the stack and it is only when I type
> (SI:GC T) at the prompt, once the compiled code has finished, that the
> collector feels free to reclaim and finalize the objects.
> This is not a bug. Finalization is not a safe thing and it is not reliable
> in the sense that you can predict when it is going to happen. It has to be
> used only as a last resort to prevent resource leakage and is no substitute
> for clever, well thought handling of those resources.

Understood. As I mentioned in an earlier message, my puspose is to
reclaim dynamically allocated foreign objects, for which finalization
has been a reasonable approach in the past. It's also good to know
that finalization functions in ECL don't have to be constrained in
functionality (i.e. being able to call FORMAT etc), though, I agree,
it's good practice to not do too much in them.

Cheers,

-ram




More information about the ecl-devel mailing list