Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector

[Peter Bex]

On Tue, Jun 19, 2012 at 08:19:08PM +0200, Felix wrote:
> There is concurrency between the garbage collector (that can kick in
> at *any* moment) and library code. The GC has a linked list of
> finalizers, allocated dynamically and theoretically unlimited in size
> (and also nicely slowing down every major GC when you have lots of
> them). But once finalizers are "triggered", they have to be stashed
> somewhere. That somewhere is the "pending finalizers vector"
> (##sys#pending-finalizers, IIRC) and that currently grows on demand.
> I _assume_ (I don't know for sure), that there is some sort of problem
> in the situation when ##sys#pending-finalizers must grow, and at the
> same time is used by GC runtime system code to hold triggered
> finalizers.

Right now it looks to me like there's an optimization that's messing
things up.  Try compiling this file with -O0 and then with -O1:

(let lp ((x (list 1 2 3)))
  (set-finalizer! x (lambda _ #f))
    (lp (list 1 2 3)))

With -O1 or higher this will raise a suspicious looking error:

Error: call of non-procedure: #<unspecified>
I also see this with 4.7.0, even when compiled with -O0.  With -O1 on
4.7.0, it shows this error and _then_ craps out with an OOM error.

The version of Megane's test in your patch also simply succeeds when
compiled with -O0.  I don't know if that's a coincidence, but that seems
a bit unlikely to me right now.  I'll try digging deeper, but this will
take time.

> It's all terribly complicated. And it's an absolute PAIN
> to debug. We can probably figure out some funky clever solution for
> this, something we can be really proud of. On the other hand, we can
> just try to simplify things a bit, have a good old decent fixed size
> buffer (out fathers weren't ashamed of them good old decent fixed size
> buffers, right?), and tell those that put finalizers onto everything
> to grow up.

Some things can currently only be handled cleanly with finalizers
if you don't want terribly imperative code that will fail whenever
you accidentally forget to clean up a resource.  I don't think we
should be forcing people to come up with workarounds to obviously
good solutions.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth