[Ecls-list] Approaching 10.3.2

[Juan Jose Garcia-Ripoll]

On Sat, Mar 20, 2010 at 1:15 PM, Alexander Gavrilov <angavrilov at gmail.com>wrote:

> By the way, I don't actually understand the logic with the
> custom finalizer queue. I looked at the source code of the
> garbage collector, and it seems that it has similar queue
> functionality built in.


I have explained it before, a couple of days or so, regarding another
finalization patch.

The situation when I wrote the code was the following:

- Function A allocates memory and there is not enough left
- The garbage collector gets invoked
- Certain objects are marked as unreachable and, if they have a finalizer,
added to a private queue of the collector.
- At this point the collector has a list of objects on which to invoke
finalizers and it does so. The world is still stopped. Allocating memory is
still unsafe. Invocation of finalizers may turn some of these objects into
reachable, thus "bringing them back to life".
- Remaining tasks for the collector are performed.

The objective of the current implementation in ECL was thus

- Only trivial finalizers are invoked. All objects with a lisp finalizer are
pushed into a queue and thus brought back to life.
- At some later point, when it is safe, finalizers are invoked and the list
is cleared.

The problem now is double. One problem is that the code in the collector has
changed. I now see that finalizers are explicitely invoked outside the
garbage collector. That is a novelty. The other problem is that our code
does not do what is expected because sometimes the finalization may be
broken if more than one object should be in the queue.

I am having a second look at the code.

Juanjo

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