Thanks, Marc! Real quick first: John Franks observed that the gsc-created C code doesn't have any calls to `free' or `*alloc', but I just checked that libgambc.so matches both. So does libgambc.so, called by `gcc ... -lgambc', set up the GC I get by gsc/gcc/a.out?
Please answer a question, asked by the computer hotshot Math professor here John Franks (a Rice pal of Clarence): does gsc/gcc implement a garbage collector? I figure it must, looking at this 112.6 GB, which you say is legit (and I've seen 435 GB too). But John points out that writing a garbage collector is serious work, and gcc doesn't have one.
Gambit's runtime system includes a garbage collector. This garbage collector is written in C and is precise (it is not a conservative GC). This is possible because the C code generated by the Gambit compiler manages its own runtime "stack" explicitly, and the GC knows how to parse the stack frames constructed by the compiler.
I'm not sure what you mean by "does gsc/gcc implement a garbage collector?" because the gcc ***compiler*** actually contains a garbage collector (but not the code that gcc generates). Moreover Gambit can be compiled with any C compiler, so the fact that Gambit contains a garbage collector has nothing to do with gcc.
May I recommend you explain this in the Gambit manual? And speaking of the manual, I haven't yet understood your position about non-experts using Gambit for a huge speed increase. Should I post what I'm thinking to cls, or should I not? Do you want to wait until version 4 is out of beta? My guess is that it's a very stable beta, as Brad has been posting about it to cls for years.
Lotta interesting stuff here I should pass on: precise vs conservative GC, gcc has an internal GC. I knew you didn't have to use gcc. By "gsc/gcc", I meant that I type
% gsc tag-t-71.scm % gcc -O2 -L. -I. tag-t-71.c tag-t-71_.c -lgambc % ./a.out
and (as I just ran again) it took 16.8 minutes, incl 6.0 minutes of GC, using 112.6 GB on a 1GB machine, and `ps -aux' says I never used more than 8%. Looks like Gambit must be flushing data out of memory in an amazing & efficient way. Especially as mzscheme ran this job 6.2 times slower, i.e. in 104.7 minutes, with only 7.5 minutes of GC:
75299 (4 8 4 5 3 5 9 3 5 7 7) (3 4 4 2 3 5 3 5 9 7 7 7) cpu time: 6282240 real time: 6316034 gc time: 455500
Here's my call to strings on libgambc:
(morse)PolyTree> strings /rhome/richter/my-gambit/lib/libgambc.so | grep alloc ___alloc_mem ___alloc_scmobj ___alloc_global_var ___alloc_rc ___bytes_allocated malloc Heap overflow while allocating stack marker
(morse)PolyTree> strings /rhome/richter/my-gambit/lib/libgambc.so | grep free ___free_mem ___free_UCS2STRING ___free_NONNULLUCS2STRINGLIST free freeing h=%p