This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: OK, what about some resolution (Re: GUILE's GC - why we struggling to solve already solved problems?)
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: OK, what about some resolution (Re: GUILE's GC - why we struggling to solve already solved problems?)
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 19 Jul 2000 15:52:04 +0200
- Cc: hanwen at cs dot uu dot nl, Jim Blandy <jimb at savonarola dot red-bean dot com>, Brent Fulgham <brent dot fulgham at xpsystems dot com>, Guile Mailing List <guile at sourceware dot cygnus dot com>
- Organization: who? me?
- References: <Pine.LNX.4.21.0007191121150.13436-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> * a garbage collector as Boehm's requires that pointers always look like
> pointers, because only pointers that look like pointers to the collector
> are treated as references to memory regions that have to be kept.
no, BGC doesn't require that -- maskable-away junk in lower-order bits
of pointers is fine by it.
> On these systems, Boehm wouldn't work. I currently don't know of other
> places within guile where this kind of problem exists.
yes, I doubt that BGC would work on a Cray. not that anyone here
would care, it seems -- I'm almost positive that Guile doesn't work on
a Cray either, what with all the changes over the years. and no
complaints about it.
indeed, compatibility with not-quite-portable C programs seems to have
become one of the important criteria for people who design new CPU
architectures, so I personally wouldn't worry about that.
> * guile requires that all of it's cells are 8 byte aligned, because
> the lower 3 bits of the address are needed for type information. When
> replacing SCM_NEWCELL with a call to a standard-style malloc, then we
> always have to over-allocate in order to be able to guarantee the 8 byte
> alignment for the actual cell data.
BGC aligns everything. in fact, we could even throw out struct data
padding with it (not sure about that though).
> * the fact that guile's cell heap and the systems's general malloc heap
> are separated gives us a variety of debugging possibilities. For
> example, the kind of checks enabled by compiling guile and extension
> code with SCM_DEBUG_CELL_ACCESSES enabled _might_ become difficult to
> provide with a system where there is simply no information about _where_
> in memory cells may occur: If cell memory is obtained via some malloc
> function that is also used to obtain memory for other purposes, there
> isn't any distinction any more.
a valid point (what of this debugging stuff is already in and what
isn't, BTW? I just lost track at some point ;().
> * when cells are collected, we need to provide our own finalization code.
> It may be possible that Boehm provides this feature.
it does. implementing guardians might turn out to be hard without
changing the BGC source, though.
> Now, having said that I don't see the performance aspect in the current
> discussion, I have to agree about the point with freeing guile from the need
> to code it's own gc. Or, in other words, it would be nice if there was a gc
> that was optimized to the way guile uses memory, that was developed and used
> separately from guile, that incorporated good gc algorithms and still would be
> pluggable into guile with minimum effort.
>
> Here's a suggestion about it:
> -----------------------------
>
> Separating the gc bits from the type tags will allow us to fully separate the
> gc subsystem from the rest of guile and put it into a separate gc library that
> then may be used also from code other than guile. The nice thing is, that
> this library can be made almost completely independent of the type system that
> is used. This allows everybody to experiment with gc, without the need to
> go into guile's internals.
yup. the last word on the issue isn't mine (the Gang of Four should
weigh in, I think), but I would be willing to help integrate the BGC
into Guile -- the GC interface is pretty well understood, and choice
is good.
[ note that it would be a choice of featuresets too -- like looking
for GC roots in static data segments or not, etc. ]
--
Those who do not learn from history, loop.