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

[felix winkelmann]

On 1/18/06, Zbigniew <address@hidden> wrote:

> I'm in the middle of adding a bunch of stuff to the objc egg, and have
> encountered a problem.  For the first time, I happened to write some
> code which consed together a few thousand Objective C objects
> (#<objc:instance>) into a list.  Suddenly, I took a gigantic speed hit
> using cons, as compared to code which simply created, used and
> discarded each object.  I tracked this down to set-finalizer!  Here is
> a simple loop which creates a finalizer for each list object, then
> conses the list objects together.
>

Ok. Finalizers work like this:

There is a list of "live" finalizers, that is finalizers that exist
for currently
live data (internally there is also a list of "allocated" finalizers -
the number
of finalizer-records kept in an internal freelist, we reuse them when
they get unused). When a major GC detects that a non-immediate
finalized data object is not forwarded (copied into the second heap-space
during GC), then it is scheduled for finalization and stored in the
"pending-finalizers" buffer (##sys#pending-finalizers). On the next
interrupt (usually after the major GC), this buffer is traversed and
the finalizer procedure is called for every entry in this buffer.
Now, this buffer has a fixed size, so we can only finalize as many
GC'd objects as fit into the buffer.
If you consider now a tight loop that allocates finalized objects, you
can come into a situation where more finalizers are created than
we can release/invoke (since they don't fit into the pending finalizers
buffer). Thus storage consumption grows even if the actual data
could be freed after GC - here we are not allowed because we
still have to invoke the finalizers. What we do currently is to force
GC if there are too many finalizers to free as many as possible.

The current solution is to increase the size of the pending-finalizers
buffer, done with the "-:fXXX" runtime option. You can also run your
code with "-:d" to see some information about finalization, or use
`(set-gc-report! ...)' to see much more information.

A more elegant approach might be to make the pending-buffer
dynamically resizable - well, it's on my every-growing todo list... ;-)


cheers,
felix