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

[Juan Jose Garcia-Ripoll]

On Sun, Mar 14, 2010 at 7:45 PM, Ram Krishnan <kriyative at gmail.com> wrote:

> Firstly, sorry for rushing off the bug report without including a test
> case.
>

No problem. The bug report by itself is valuable, but the test case is
needed to help debug the problem and the potential fix.

Secondly, I was wrong about the crashing behavior. After I'd sent my
> bug report, I realized I had a call to FORMAT inside of the finalizer,
> which is likely to cons and presumably cause unexpected behavior.
> Removing that call to FORMAT eliminated the crashing behavior. So,
> please disregard that.
>

No, it should not be disregarded. The goal is that it is safe to execute
_arbitrary_ code in the finalizers. If FORMAT broke it then obviously the
code is not working fine.


> However, the issue with only part of the queued objects being gc'ed
> remains, as evidenced by the test case above.
>

I will look at it carefully


> Lastly, thanks for explaining queueing_finalizer(), and I appreciate
> the motivation, but, I still don't follow the logic. Just so I have it
> right, this is what I understood from your explanation:
>
>  - new object gets assigned a finalizer
>  - eventually, object is marked garbage
>  - gc calls finalizer
>  - finalizer is added to a queue, and will be called when that queue
> becomes garbage
>

Actually I am not sure I want the queue to be finalized when it becomes
garbage, but rather as soon as possible after this or the next collection
would be fine. I will have to look at the code. I am just talking out of
memory content and my RAM is error prone :-)


> If a set of objects have inter-dependencies when they are first passed
> into queueing_finalizer() (and get pushed into to_be_finalized), won't
> those same dependencies exist when queueing_finalizer() is reinvoked
> on the to_be_finalized queue? How is the dependency situation any
> different in the second go around?
>

The problem is not dependencies, but having all content sane and accessible.
Finalized objects have to be valid objects when the finalizer is called and
it has to be safe to execute arbitrary code in the finalizer. Given this,
there is no other guarantee: no order is guaranteed when calling the
finalizers and your code should be aware of that.

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/20100314/81d53e33/attachment.html>