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: OK, what about some resolution (Re: GUILE's GC - why we struggling to solve already solved problems?)


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.


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