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:

> 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


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