> 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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
