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: Again: Guile + Boehm's gc


23-Jul-00 10:59 you wrote:
> Hello All,

> I have a slightly different take on using Boehm's GC in guile.  As far
> as I can see, if the goal is to make Guile's GC transparent to the
> application it will be necessary to replace malloc with Boehm's
> malloc.

No. You can use your standard system malloc and Boehm's GC.

> That's a pretty intrusive requirement.  For instance, what happens if
> I want to use tools like electric-fence or ccmalloc (malloc debuggers) to
> look for dangling pointers.

Just use them.

> That works with the current GC, it doesn't work when BGC has replaced malloc.

BG CAN replace malloc. It's NOT requirement though.

> It is possible to use GC_malloc (from boehm), for guile, and regular
> malloc for the rest of the application, but I'm pretty sure that would
> require as many special rules as the current GC.

You can mix GC_malloc and regular malloc as much as you want. The only
rule is to NOT use free for memory obtained via normal malloc (pretty
obvious: free from system library will not know what to do with object
allocated with GC_malloc).

> Hopefully, I'm wrong.  There is a certain appeal in guile using a standard,
> well known, GC that "just works", but I'm afraid that BGC may not be that
> transparent.

It's MUCH more transparent then current guile's GC. It's MUCH safer: with
GUILE's GC you can screw system quite badly when you'll forget about
scm_protect/unprotect thing. VERY unconvenient thing for programmer
familiar with Perl/Python/etc embedding rules. It's usual tradeoff in fact:
speed vs safety. Boehm's GC is slower then GUILE's GC (sometimes difference
is small and can be made close to zero with proper tuning but sometimes it'll
be HUGE: think about scientific application with 500MiB array in heap -- without
using GC_malloc_atomic Boehm's GC will try to scan this huge blob for pointers
and probably will even succed sometimes and if you'll redefine standart malloc
as GC_malloc_atomic you'll need scm_protect/scn_unprotect call just like
guile's standard GC) but it's MUCH more convenient for embedders who do not
care much about speed issues but want easy and fast (fast when programmer time
is counted, not program time :-) way to extend application.

Still module system and GOOPS integration are MUCH more important and much
more wanted so let's postpone Boehm's integration discussion (as THE guile's
GC or as ALTERNATIVE guile's GC) for now.




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