On 1/18/06, Zbigniew <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
