Re: garbage collectors

[Miroslav Silovic <silovic@zesoi.fer.hr>]

Jens-Ulrik Holger Petersen <petersen@kurims.kyoto-u.ac.jp> writes:

> [Sorry, if this is an old thread.]
> 
> There has been another small discussion on the xemacs-beta list about
> Garbage Collection in a future Scheme-based (X)Emacs....
> 
> A worrying critism, I have heard against Guile, is that it's
> Conservative Garbage Collector is not suitable for "big applications"
> like (X)Emacs, since it is thought that Conservative GC is not "safe"
> under C.  It was rumoured that after some hours of intensive usage of
> emacs, memory usage would start to bloat considerably, making it hard
> to keep an (X)Emacs running for long periods.

Hmm, the keywords above seems to be 'rumored' and 'would'. Those, IMO,
shouldn't be used in the same sentence with 'considerably' - the
problem is that we just don't /know/ how conservative GC performs.

One thing is that Guile's conservative GC is different from the
standard conservative GC (used with pure C programs). While standard
conservative does binary scan of all allocated blocks, Guile only
binary-scans the stack, and only looks for the pointers on the heap.
>From there, it's standard mark & sweep (and you're required to provide
mark routines for your own datatypes). This seems very unlikely to
leak memory, as stack can only give a constant-limited number of false
roots. The worst that can happen to you is that one or two large
datastructures fail to be GC'ed. That, ho5wever, will not cause the
memory usage to grow linearily with time.

My own experience is that I ran rather large numbercrunching
application with lots of garbage production, as well (raytracer, with
lots of weird features that make things appear and disappear at
random).  After running for hours, the only time it starts to bloat is
when I repeatedly allocate HUGE arrays, however, the reason for bloat
in that case was that it caused Guile to raise memory allocation limit
for invoking GC, and since the raytracer used to allocate large number
of larger-than-cell structures, memory allocated for arrays was never
freed - and then it'd allocate another huge array, in the
loop. However, this would explode classical GC, as well. During normal
use, memory stayed constant.

To summarize, since the number of false roots is limited by a
constant, I think you shouldn't have any problems.

That said, I'd love to see xemacs based on CMUCL. ;)

-- 
I refuse to use .sig