Inconsistency when calling set-finalizer! multiple times on the same object

[Moritz Heidkamp]

The following program prints "b" when interpreted and "ba" when compiled:

(define x (list 1))
(set-finalizer! x (lambda (x) (display 'a)))
(set-finalizer! x (lambda (x) (display 'b)))
(set! x #f)

I am not sure whether replacing the existing finalizer or appending another finalizer makes more sense. However, it would probably be better if both cases behaved the same.

[Jim Ursetto]

Weird. I increased your finalizers to 3 and added a (gc #t) to the end as well. Both cases look like they are behaving strangely.

Compiled:

;; (gc #t)
[debug] running 1 finalizers (2 live, 3 allocated) ...
c[debug] running 1 finalizers (1 live, 3 allocated) ...
b[debug] running 1 finalizers (0 live, 3 allocated) ...
;; program end
[debug] forcing finalizers...
a[debug] application terminated normally

Interpreted (csi -script):

;; (gc #t)
[debug] running 1 finalizers (2 live, 3 allocated) ...
;; program end
[debug] forcing finalizers...
c[debug] application terminated normally

[felix winkelmann]

This should be fixed now (experimental). The code that walked the finalizer list checks for a finalized object being not forwarded into the new heap area on GC. Previously it marked the object, hiding the "non-forwarded" status for later finalizers for the same object in the finalizer list, which would then never be run. The list is now walked twice, once for checking, and once for marking. GC frequency and the location of objects in memory influence strongly how and when finalizers are checked and executed.

I have tried to improve the documentation.

[Moritz Heidkamp]

Works like a charm, thanks a lot :-) The docs are clear to me now!

[felix winkelmann]

Milestone 4.7.0 deleted

[felix winkelmann]

Milestone 4.8.0 deleted