[plt-scheme] Garbage collection woes

Hope you don't mind my re-ordering your email, I didn't try the
options in the order you suggested them =).

On 09/11/2007, Matthew Flatt <mflatt at cs.utah.edu> wrote
> Since the collector bases its nursery size on the amount of memory
> already allocated, you can partially simulate this (without rebuilding
> the binaries) by allocating a large string at the beginning of your
> program.

I tried this, and indeed it reduces the number of pauses. It takes far
too much ram though. =)

> As an experiment, you might try building with the "compact" 3m
> collector, which uses 4 or 5 generations instead of just two (nursery
> and mature). Under Unix variants, building with the compact collector
> is as easy as configuring with the --enable-compact option. For a
> Windows build, change the definition `(define accounting-gc? #t)' to #f
> in the file "plt/src/worksp/gc2/make.ss".
>
> The "compact" collector is different in many ways from the default one,
> so it's not a great test for whether multiple generations can help.
> Unfortunately, changing the default collector to use multiple
> generations is not so easy.
>

I tried modifying gentoo's v371 ebuild to add that config flag, but I
get a compile error:

---
/home/non-user/tmp/portage/dev-scheme/drscheme-371/work/plt-371/src/lt/libtool
--mode=compile --tag=CC i686-pc-linux-gnu-gcc -O2 -march=i686 -pipe
-DUSE_COMPACT_3M_GC  -DMZ_USES_SHARED_LIB -I./.. -I./../include   -c
./gc2.c -o gc2.lo
  i686-pc-linux-gnu-gcc -O2 -march=i686 -pipe -DUSE_COMPACT_3M_GC
-DMZ_USES_SHARED_LIB -I./.. -I./../include -c ./gc2.c  -fPIC -DPIC -o
.libs/gc2.o
In file included from ./gc2.c:5:
./compact.c:2679: error: static declaration of 'designate_modified'
follows non-static declaration
./compact.c:2641: error: previous implicit declaration of
'designate_modified' was here
make[4]: *** [gc2.lo] Error 1
make[4]: Leaving directory
`/home/non-user/tmp/portage/dev-scheme/drscheme-371/work/plt-371/src/mzscheme/gc2'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/non-user/tmp/portage/dev-scheme/drscheme-371/work/plt-371/src/mzscheme/gc2'
make[2]: *** [3m] Error 2
make[2]: Leaving directory
`/home/non-user/tmp/portage/dev-scheme/drscheme-371/work/plt-371/src/mzscheme'
make[1]: *** [3m] Error 2
make[1]: Leaving directory
`/home/non-user/tmp/portage/dev-scheme/drscheme-371/work/plt-371/src'
make: *** [all] Error 2
---

Not sure what would be the proper way to fix this, but after writing
and applying the following patch:

---
diff -cr plt-370/src/mzscheme/gc2/compact.c
plt-370.new/src/mzscheme/gc2/compact.c
*** plt-370/src/mzscheme/gc2/compact.c  2007-05-12 19:09:13.000000000 -0400
--- plt-370.new/src/mzscheme/gc2/compact.c      2007-11-09
14:00:12.000000000 -0500
***************
*** 2619,2624 ****
--- 2619,2626 ----

  #if GENERATIONS

+ static int designate_modified(void *p);
+
  static int designate_modified_maybe(void *p, int no_barrier_ok)
  {
    unsigned long g = ((unsigned long)p >> MAPS_SHIFT);
---

It compiles fine, but then I get this:

---
henk at korhal ~/dev/scheme/metas $ mzscheme -u run.ss
Access on unmapped page at 974feea4 [0]
Aborted
---

So much for that. >_>

> I agree with the idea of making more of the knobs dynamic and making
> them more available.

Indeed. Back when I made normal use of Java, I hated that there was no
way for the application to specify that it wanted the incremental
garbage collector at runtime. You needed to do it on the command line,
which made it impossible for applets.

Of course, the ideal solution would be for mzscheme to have an
incremental collector (like the train algorithm or similar), but I
recognize that this is a pretty tricky bit of programming, and would
take a lot of work to implement.

    Henk Boom