Re: guile/guile-core/libguile init.c

[Greg Harvey <Greg dot Harvey at thezone dot net>]

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