This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: boehm & guile, success report.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]