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)



> > 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.

I'm not going to address the vague assertions about how easy or hard
Guile is to use.

As to the specific point, I think it's fine for an application to tell
you how to use its datatypes.  I think it's good design for Guile to
provide a C API in which all Guile objects are opaque, and mutations
occur through Guile functions, which take care of invoking write
barriers appropriately.

> 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.

I'm very interested in seeing the results of an actual try.  Would you
be willing to try the experiment, and tell us how it goes?


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