2003-08-30 12:16:52 -04:00
|
|
|
$Id$
|
2003-08-30 12:07:52 -04:00
|
|
|
|
2003-08-19 15:19:38 -04:00
|
|
|
Generational/Incremental Garbage Collector
|
|
|
|
|
|
|
|
The generational, incremental garbage collector still is considered
|
|
|
|
experimental, although it stands up well in some real applications.
|
|
|
|
Here is a list of known problems:
|
|
|
|
|
|
|
|
o On a Sun (Sun-4/SunOS4 or 5) when compiling Elk with gcc (2.6.3
|
|
|
|
or older), the generational garbage collector sometimes loops
|
|
|
|
(when working in non-incremental mode). This can be circumvented
|
|
|
|
by compiling src/proc.c (yes, proc.c, not heap.c) without the -O
|
|
|
|
option. We are not sure yet whether this is a bug in Elk or in gcc.
|
|
|
|
|
|
|
|
o Running out of memory when expanding the heap shouldn't be handled
|
|
|
|
as a fatal error. Instead, the garbage collector should clean up
|
|
|
|
and then invoke Uncatchable_Error() to return control to the Scheme
|
|
|
|
program.
|
|
|
|
|
|
|
|
o The return value of ExpandHeap() is sometimes ignored.
|
|
|
|
|
|
|
|
o When running the program
|
|
|
|
|
|
|
|
(garbage-collect-status 'generational 'incremental)
|
|
|
|
(define (f) (make-list 10000 'a) (f))
|
|
|
|
(f)
|
|
|
|
|
|
|
|
the pairs in the lists become stable quickly and aren't reclaimed,
|
|
|
|
as the current algorithm favors heap expansions over full collections.
|
|
|
|
|
|
|
|
o With the same test program, the GC sometimes crashes with SIGSEGV
|
|
|
|
after having expanded the heap to 9MB.
|
|
|
|
|
|
|
|
o Under HP-UX 9.0 and AIX 4.1, the GC doesn't work in incremental mode
|
|
|
|
(a broken-heart is passed to Memoize_Frame() after an ExpandHeap()).
|
|
|
|
|
|
|
|
o The percentage displayed at the end of a GC run is sometimes wrong.
|
2003-08-19 15:24:23 -04:00
|
|
|
|
|
|
|
o This simple test causes a valgrind error after the first GC run:
|
|
|
|
|
|
|
|
(define (fact x) (if (> x 1) (* x (fact (- x 1))) 1))
|
|
|
|
(fact 100)
|
|
|
|
(fact 1000)
|
|
|
|
(fact 1000)
|
|
|
|
|