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: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)


18-Jul-00 12:22 you wrote:

>> >> You aren't describing the Boehm GC here.  It also has generational
>> >> capability.  Boehm is working on making it concurrent as well.
>>
>> Jim> What kind of write barrier does it have?
>>
>> It uses the VM.

> Okay --- this illustrates my only objection to the Boehm GC.

> Boehm is really sharp.  His papers are excellent; the posts I've read
> from him are a step above.  I'm sure he does a lot of stuff better
> than we would on our own --- we should be watching his ideas closely.

> But his GC is trying to solve a harder problem than ours: he's trying
> to replace malloc in GC-ignorant programs.  In Guile, we can demand a
> lot more from our code:
> - We can require that they use a software write barrier.

Not exactly true. Guile is EXTENSION language, not just scheme interpreter,
right ? Most application developers just DO NOT want to bother itself with
any write barriers. They usually want just extension language "ready to use
out of the box with minimal knowleadge". This is not GUILE in current state,
I afraid.

>   Software write barriers are much more efficient than Unix VM barriers,
>   according to all the papers I've read.  But for Boehm, it's not an option.

It's bad option for guile as well: it should affect host program as less as
possible.

> - We can require that all their objects start with cells, from which we
>   can extract typing information quickly and reliably.

And then Boehm's GC can use this information easily (Ok, it requres type
information to be embedded in object in some particular way but it does
not look like unsolvable problem). Take look on gcj_mlc.c ...

> - We can focus our energies on allocating cells of a few small sizes,
>   instead of arbitrary-sized blocks.

Boehm's GC as special code to speedup allocation of small cells (up to 4K).

Boehm's GC has A LOT OF things to make efficieng GC in specuial cases possible.
Of course it's not for everyone and thus you must use some internal functions.
Still it's possible (the same gcj_mlc.c will be good example). Of course it's
quite possible then general-purpose GC still will be less efficient then
special-purpose GUILE's one. There are no way to know without actual try.

> Now, those are the theoretical arguments, and must be taken with a
> grain of salt.  The clincher would be benchmark results, in either
> direction.  If Boehm is competitive with the (still non-existent,
> right?) Guile generational GC, then I would suggest that we get out of
> the GC business, and delegate the maintenance of our GC to Boehm.




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