This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: guile/guile-core/libguile init.c
- To: Jim Blandy <jimb at red-bean dot com>
- Subject: Re: guile/guile-core/libguile init.c
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 15 Mar 2000 08:32:35 +0100
- Cc: guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <20000314151212.6846.qmail@sourceware.cygnus.com> <m3ln3l9u4r.fsf@savonarola.red-bean.com>
Jim Blandy <jimb@red-bean.com> writes:
> In his thesis, Ben Zorn recommends that one should not GC when the
> freelist is exhausted. If you do this, then programs whose data size
> is close to the current heap size will GC very frequently, because the
> freelists will always be short. And since these GC's will reclaim
> very little storage, the time they take is pretty much wasted.
I have implemented this scheme and comittedit to the repository.
You get it by defining
GUILE_NEW_GC_SCHEME
in __scm.h.
It still contains bugs. One is associated with guardians. (I haven't
looked closely at guardians relative to this change yet.) Please help
me find the bugs! :-)
Two nice things:
* Guile seems to start and run faster with this change
* Heap sizes adapt themselves so that Guile automatically finds a good
working point for the floating point benchmarks: Guile with 2-word
cells + this change *is* faster on floating point calculations than
old Guile!