This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: boehm & guile, success report.
Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> mlivshin@bigfoot.com writes:
> > hello, the fearless one.
>
> [uhh, is that me?]
apparently.
> > 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 don't deal with anything, Boehm is designed to be a drop-in
> replacement for malloc. Since I expect that lots of C programs also
> allocate large numbers of small obejcts, it should work reasonably
> with GUILE.
ah, you mean that every SCM_NEWCELL is actually a GC_malloc()? this
is a valid approach, but it'll require some tag structure redesign to
be really usable. still, could be done.
> > > 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.
>
> One of my colleagues did a literature survey on GC, and found out that
> most compilers and interpreters got better by dropping their in-house
> developed gc in favor of BGC.
I have at least one contrary experience, but I'm not allowed to tell
where it was.
can you give a pointer to that survey? (I hope it's online).
> In any case Bigloo also uses BGC, so it should be feasible.
nobody said it's not feasible. (MzScheme and Stalin also use it,
IIRC).
> > > * no more weird distinctions between stack and heap
> >
> > it's not weird at all, IMHO.
>
> it is. It gets very messy if you have a C++ program that allocates specific
> structures both on the heap, and on the stack, and as a compound
> object on the heap.
>
> (Yes, I know , C++ sucks. You should have told me 5 years ago)
well, for all C++'s suckiness, it could easily let you use a *precise*
GC -- there's enough language support to track any SCM reference. so
don't scan such structures conservatively.
the whole conservative stack scanning thing is there because you can't
tell C to do something when a stack-allocated object goes in/out of
scope -- that's the reason why I think that the distinction between
stack and heap is very much valid.
[ in fact, in the long run, I think that it would be very worthwhile
to divorce the Scheme execution stack from the C one. apart from
making continuations much cheaper, this would make the need to know
the C stack origin unnesessary, etc. but that's stuff for a
separate discussion. ]
--
For those who like this sort of thing, this is the sort of thing they like.
-- fortune