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: 14 Mar 2000 22:43:33 +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.
>
> He suggests that the program should instead expand the heap whenever
> the freelist is exhausted, and GC after every N allocations, where N
> is a parameter. This way, the heap size naturally adjusts to match
> the program's data size, and the GC frequency is more controlled.
This sounds good.
I suggest that we replace the current double mechanism
SCM_INIT_HEAP_SIZE-EXPMEM / SCM_HEAP_SEG_SIZE with the mechanism you
describe.
OK?