Re: the future of Guile

[Kjetil S. Matheussen]

On Tue, 4 Dec 2007, Roland Orre wrote:

> On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
> ...
> > Oh, and another thing. My tests (available in the guile-devel archives)
> > also showed that the HBGC version usually use a bit less memory
> > than Guile's old garbage collector. (Yet another "should"
> > for replacing. :-) )
>
> I don't have much experience with different GC algorithms, but
> as I understand the HBGC is not intended for background GC.

Actually, it does:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html



> If the GC should be replaced I would consider it wise to
> replace it with an algorithm than can be run in a thread.
> This I consider strongly motivated by the fact that most new
> machines today are multi core. An efficient way to decrease the
> latency of the GC is to simply run it in background.

Sure, that would be great. But I don't think you know how hard
it is to actually do that... But as a matter of fact, the HBGC do
at least support parallell marking though, and I also think the
HBGC patch for guile supports that feature.



> Regarding GC I also think it is could be useful to have a GC that
> can compact the memory

I think the HB gc does a pretty good job of not fragmenting the memory
at least.



> and of course give allocated memory back to
> the OS when no longer needed.

Well, Don't think you need that feature very often when using an OS 
supporting virtual memory.


Anyway, there is no third option here. The two choices are Guile's 
own garbage collector and Hans Boehms general garbage collector.
The last one is used in a bunch of other programming languages with great 
success, and except for being a bit slower on uniprocessor machines
when running a garbage collector benchmark, the HBGC seems
to generally work better for Guile than Guile's own GC.

Personally I hope the Guile developers choose to switch to HBGC when 
starting the next development cycle of Guile.