Re: [Chicken-users] set-finalizer! and cons

[Zbigniew]

For what it's worth, attached is a quick and dirty patch to resize the
pending finalizer buffer upward dynamically.  Not being an expert in
Chicken internals, I'm sure there are subtleties I overlooked.

Example run: 5600 finalizers, normally takes 27 seconds and 3575 major
GCs (at -:f2048), and just for fun here I set -:f32.

#;5> ,t (define L (ns:enumerator-fold-right cons '() (@ tracks key-enumerator)))
[debug] too many finalizers (33), resized max finalizers to 64...
[debug] too many finalizers (65), resized max finalizers to 128...
[debug] too many finalizers (129), resized max finalizers to 256...
[debug] too many finalizers (257), resized max finalizers to 512...
[debug] too many finalizers (513), resized max finalizers to 1024...
[debug] too many finalizers (1025), resized max finalizers to 2048...
[debug] too many finalizers (2049), resized max finalizers to 4096...
[debug] resizing heap dynamically from    f4d80 to   1e9b00 bytes...
[debug] too many finalizers (4097), resized max finalizers to 8192...
   0.305 seconds elapsed
 2.4e-02 seconds in (major) GC
    5619 mutations
     182 minor GCs
       3 major GCs
#;6> (gc #t)
[debug] running 1 finalizers (5623 live, 5624 allocated) ...
594284
#;7> (define L '())
#;8> (gc #t)
[debug] running 5617 finalizers (6 live, 5624 allocated) ...
[debug] resizing heap dynamically from   1e8688 to    f4344 bytes...
272588

On 1/23/06, felix winkelmann <address@hidden> wrote:
> On 1/23/06, Zbigniew <address@hidden> wrote:
> > Sorry if I'm being dense---why does it need to release any finalizers
> > at all, if the pending buffer is totally empty?  I thought the size of
> > the pending buffer was the issue here.
> >
>
> It's me who is dense, I guess - even if the pending buffer is empty we
> force a GC in the hope of filling up the buffer, so that we can then run
> the finalizers. It's likely that I'm overlooking the obvious, but the main
> problem as it appears to me is that we should avoid registering
> finalizers, once the live count goes above the pending buffer size.
> Otherwise we have more live finalizers that may be reclaimed in one
> go, which would result in a space leak in tight loops. I tested this
> with the numbers egg, doing bignum calculations in a loop, and
> getting it to work without leaking space (by forcing finalization through
> repeated GC) was a major piece of work. The mechanism used is
> likely to be suboptimal, but I haven't found a perfect solution yet.
> Any suggestions are of course welcome.
>
>
> cheers,
> felix
>

chicken-2.207-finalizers.diff
Description: Binary data