File: BUGS

package info (click to toggle)
elk 3.0-8.1
  • links: PTS
  • area: main
  • in suites: woody
  • size: 4,088 kB
  • ctags: 3,115
  • sloc: ansic: 20,686; lisp: 5,232; makefile: 411; awk: 91; sh: 19
file content (35 lines) | stat: -rw-r--r-- 1,505 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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.