This is the mail archive of the guile@cygnus.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: gh_enter reconsidered


"Perry E. Metzger" <perry@piermont.com> writes:

> Jim Blandy writes:
> > In the absence of really exciting new hacks I haven't heard of, Guile
> > will continue to use conservative GC.  The alternatives --- explicitly
> > marking heap pointers, and reference counting --- are clearly
> > unacceptable, given Guile's goals.  I have direct long-term experience
> > trying to use the first, and the second doesn't support Scheme's
> > semantics.
> 
> I've often wondered whether a combination reference count/mark & sweep 
> collector, that generally freed objects quickly (thanks to reference
> counting) but periodically found circular structures with marking
> would be of any use.

Reference counting wouldn't necessarily speed things up at all. It
will remove the need for some marking, but will result in a hassle for
c code (could be worked around, but will either require annoying book
keeping, or not refcounting stack traced objects... but that could
only be done if you do at least a partial mark), possibly increased
sweep time (since heaps would likely be bigger because of more
objects), the overhead for refcounting (could be small or large,
depending on whether you keep a larger count than can be squeezed out
of the current tags).

> 
> Frankly, though, Guile has a lot of problems right now, none of which
> have anything to do with the GC it uses. There's no documentation, it
> is slow, 

>From the (admittedly small amount of) profiling I've done, the gc is
one of the largest time consumers in guile (I think startup was
something like 50% gc, though I tested before the pre_write & pre_read
changes, who might be serious contenders now). Making startup not
create so much garbage would be a good thing, but it still doesn't
look good for gc.

> it doesn't have the sort of interfaces or module system it
> needs, etc. It isn't a worthy competitor to things like Perl, at least 
> not yet. Once the basic problems are further along, maybe spending
> time on GC would be good....

Naw, gc is more fun than trying to convert the perl heathens ;)
-- 
Greg