This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: guile/guile-core/libguile init.c
Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> Greg Harvey <Greg.Harvey@thezone.net> writes:
>
> > Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> >
> > > Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> > >
> > > > I took the Ben Zorn idea to allocated heap when freelist is empty
> > > > and GC after N cells (the GC trigger) but added that GC won't happen
> > > > if there happens to be yet another N cells on the freelist.
> > >
> > > Correction: GC won't happen until the rest of the freelist has been
> > > consumed (the point where heap growth normally would occur).
> >
> > Umm... so nothing's changed, except getting a new cell is more
> > complicated?
>
> Well, "worse is better", right? ;-)
>
> Actually, the two schemes are more similar than I first realized.
> Sorry for being so dense.
>
> But, the new code actually does solve two problems:
>
> 1. How to coordinate GC for multiple freelists (1-word, 2-word, ...)
>
> 2. How to support pre-emptive multi-threading
>
> It differs from the old GC scheme the way you suggested in a previous
> letter: the minimum GC yield is *constant* and the heap is grown with
> a factor 1.5 instead of 3.
A constant minimum gc yield is a *very* bad thing; it'll actually end
up making the problem it's trying to solve (working set of program
very close to the heap size) worse than the current (old... temporal
flux ;) method, since you could end up with a working set at something
like heapsize - xN (x being small), so you collect an awful lot just
for utility functions; no biggie for small problems, but if you were
using scwm, you'd probably get a collection every time you moved a
window further than a few pixels (urgh).
For growth, I really think that, past a point, it should only grow by
a constant (this is different from my gc changes, in that it always
grows by a constant, after the second segment); this is again a high
memory thing, but if you have a 20 megabyte heap, and you need to
grow, chances are, it's not going to be for another 30 megabytes; both
scwm and Lynn Winebarger's disassembler thing really benefited from a
fixed maximum reallocation size (with some tinkering with heap
segments to about 2 megabytes, scwm really sped up for starting (~ 100
in gc time over 1.3.4)).
The other changes I like (the only time you mention something is when
it irks you ;).
--
Gregh