Guile + Boehm GC

Guile + Boehm GC

[Ludovic Courtès]

Hi all,

Integration of Boehm's GC within Guile was discussed at length in the
past, especially back in 2000.  Apparently, Han-Wen even got to the
point of having an preliminary implementation of Guile that uses it[0].
Unfortunately the URL mentioned there is no longer valid.

Han-Wen: Could you summarize your conclusions and maybe make your code
available as well?

More generally, do people (still) believe that Guile should use BGC?
Back then, there was apparently some consensus that it would be a Good
Thing.

Thanks,
Ludovic.

[0] http://sources.redhat.com/ml/guile/2000-07/msg00252.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile + Boehm GC

[Nic]

ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) writes:

> Hi all,
>
> Integration of Boehm's GC within Guile was discussed at length in the
> past, especially back in 2000.  Apparently, Han-Wen even got to the
> point of having an preliminary implementation of Guile that uses it[0].
> Unfortunately the URL mentioned there is no longer valid.
>
> Han-Wen: Could you summarize your conclusions and maybe make your code
> available as well?
>
> More generally, do people (still) believe that Guile should use BGC?
> Back then, there was apparently some consensus that it would be a Good
> Thing.

I looked at this about 2 years ago. My goodness it was complicated.

I thought that there was a good argument for overhauling the objects
and the GC together. I thought it would be particularly interesting if
glib objects were used as guile's objects. This wouldn't make
overhauling the GC any easier (except by removing cruft) but it would
be a worthwhile exercise in reduction IMHO.


Nic Ferrier


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile + Boehm GC

[Han-Wen Nienhuys]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

In article <87hd5rgafd.fsf@laas.fr>,
Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>Hi all,
>
>Integration of Boehm's GC within Guile was discussed at length in the
>past, especially back in 2000.  Apparently, Han-Wen even got to the
>point of having an preliminary implementation of Guile that uses it[0].
>Unfortunately the URL mentioned there is no longer valid.
>
>Han-Wen: Could you summarize your conclusions and maybe make your code
>available as well?

it's here,

  http://www.xs4all.nl/~hanwen/public/guile/guile-boehm.gz

note that this is a patch for the "old" GC code, before I took a stab
at rewriting.

It was a quick hack, and performance was a little worse, but I think
it could be just as performant as GGC. Note that many interpreters
(eg. MzScheme) use BGC by default.  Also, measuring performance of GC
is hard, since there is a space/time tradeoff, so you should really
measure the tradeoff, something I haven't done.

>More generally, do people (still) believe that Guile should use BGC?
>Back then, there was apparently some consensus that it would be a Good
>Thing.

I think it would be good to move to BGC. BGC is used by many other
interpreters, and receives more attention wrt performance and
bugfixing than GGC. Dropping code is almost always good


BTW, I ran across Judy trees today,

  http://judy.sourceforge.net/

would it be worthwhile to try replacing resizing hash tables in Guile
with Judy trees? I expect that it would incur a significant speedup.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile + Boehm GC

[Ludovic Courtès]

Hi Han-Wen,

lilydev@muurbloem.xs4all.nl (Han-Wen Nienhuys) writes:

> it's here,
>
>   http://www.xs4all.nl/~hanwen/public/guile/guile-boehm.gz
>
> note that this is a patch for the "old" GC code, before I took a stab
> at rewriting.

The good news is that it looks quite simple!  The main changes are
located here (diffstat):

 libguile/gc.c                 |  854 +-----------------------------------------
 libguile/gc.h                 |   57 --

However, it looks like you didn't look at weak hash tables back then.
My impression is that porting them would be the most difficult task.

> It was a quick hack, and performance was a little worse, but I think
> it could be just as performant as GGC. Note that many interpreters
> (eg. MzScheme) use BGC by default.  Also, measuring performance of GC
> is hard, since there is a space/time tradeoff, so you should really
> measure the tradeoff, something I haven't done.

Yes.  But GGC's performance is terrible IMO (see my posts a few months
ago), and also GGC is used only within Guile.  So I'm confident that BGC
may work better, and even if it doesn't, chances are that it may improve
over time given the number of users it has had.

> I think it would be good to move to BGC. BGC is used by many other
> interpreters, and receives more attention wrt performance and
> bugfixing than GGC. Dropping code is almost always good

Agreed.

> BTW, I ran across Judy trees today,
>
>   http://judy.sourceforge.net/
>
> would it be worthwhile to try replacing resizing hash tables in Guile
> with Judy trees? I expect that it would incur a significant speedup.

I was not aware of this project but I'm not so sure it would have a
significant impact.  Currently, Guile spends a huge amount of time
managing memory and improving this should be priority #1 I think.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Guile + Boehm GC

[Han-Wen Nienhuys]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

In article <87r74vd858.fsf@laas.fr>,
Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>>
>>   http://www.xs4all.nl/~hanwen/public/guile/guile-boehm.gz
>>
>> note that this is a patch for the "old" GC code, before I took a stab
>> at rewriting.
>
>The good news is that it looks quite simple!  The main changes are
>located here (diffstat):
>
> libguile/gc.c                 |  854 +-----------------------------------------
> libguile/gc.h                 |   57 --
>
>However, it looks like you didn't look at weak hash tables back then.
>My impression is that porting them would be the most difficult task.


Yes, correct. It was a quick hack.

>> BTW, I ran across Judy trees today,
>>
>>   http://judy.sourceforge.net/
>>
>> would it be worthwhile to try replacing resizing hash tables in Guile
>> with Judy trees? I expect that it would incur a significant speedup.
>
>I was not aware of this project but I'm not so sure it would have a
>significant impact.  Currently, Guile spends a huge amount of time
>managing memory and improving this should be priority #1 I think.

Quite possibly, but LilyPond is my main application, and Lily also
spends a lot of time doing various kinds of hashtable lookups.




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel