This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: boehm & guile, success report.
- To: hanwen at cs dot uu dot nl
- Subject: Re: boehm & guile, success report.
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 18 Jul 2000 13:46:49 +0200
- Cc: guile at sourceware dot cygnus dot com
- Organization: who? me?
- References: <14708.16528.532598.604749@dokkum.cs.uu.nl>
Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> Hi there.
hello, the fearless one.
> It was actually very easy to do, replacing guile's GC only involves
> deleting some of code :-) -- it doesn't track weak refernces, and I
> wonder it does the correct thing wrt structs, but I succesfully booted
> GUILE with it.
I don't have any time right now to actually look at the code, so I
hope you don't mind me asking here:
how do you deal with cells? if you use the Boehm collector
simplistically, with the default settings, then I'd assume that a
reference to one cell retains a whole segment. right?
> I do think it is a major win if GUILE uses it:
>
> * generational GC
I believe we can do *much* better, but that's indeed something.
> * no more weird distinctions between stack and heap
it's not weird at all, IMHO. moreover, the detection of static data
areas in shared libraries is pretty platform-specific and brittle (or
at least that was my impression).
> * no more effort to spend on GC: we can focus on other things.
perhaps.
> I couldn't get the benchmark package to work (can someone look at this
> some time? I 'd like to run a benchmark by doing
>
> my_guile BENCHMARKDIR/benchmark.scm BENCHMARKDIR gc ports
well, you could implement `gc-stats' by translating Boehm's statistics
into Guile ones -- that would make the benchmark package happy. but
that seems pretty meaningless at this stage. perhaps you could just
do several `time' runs of some nice big batch Guile-using program, and
compare that.
> having to edit files and fiddle with stuff is a major turnoff.)
interesting position ;).
P.S. don't get me wrong, it's tres cool that you are doing this.
it's very important to have concrete info about the available
options.
--
... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS.
-- Erik Naggum