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

[Felix]

> 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.

Compiling without optimizations means more CPS calls, which means more
nursery allocation, which means more minor GCs, which means more major
GCs, which means faster triggering of finalizer which means less
pressure to resize ##sys#pending-finalizers. Everything that allocates
influences GC and thugs finalization. Normal execution of code
allocates activation frames.

> 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.

I don't see how limiting the available number of finalizers "forces
people to come up with workarounds". We are talking about excessively
creating finalizers. In fact, the only code I've seen that actually
causes the problems are contrived finalizer-creation loops. I'm not
against the use of finalizers and I don't understand how you come to
that conclusion. They are a workaround that is, unfortunately,
sometimes necessary.


cheers,
felix