Re: gc notes available

[Greg Harvey <Greg.Harvey@thezone.net>]

Jim Blandy <jimb@red-bean.com> writes:

> I'm concerned first with reducing the overall cost of GC, and second
> with providing acceptable interactive behavior.
> 
> I have read that most incremental collectors limit the absolute pause
> length, but consume more time overall than non-incremental collectors.
> I don't want to come out of this with Guile spending *more* time in
> the collector than it does now.  I'm not interested enough in games
> and animations to make that trade.

I've not seen anything to suggest otherwise, since that's the only
real motivation for incremental collection. A generic scheme
implementation, running under a generic os, isn't going to be able to
fill the role of real-time programming environment anyway, so it
probably doesn't make an awful lot of sense to increase memory and
computational requirements for guile in general (particularly if
people start a lynch mob for the gc implementor who sacrificed a
quicker gc to accommodate guile-doom)

With some configurable bits of the gc, it should allow most
applications in the 'interactive, but doesn't launch nuclear oblivion
because of a slight pause' catagory to get the desired performance, at
the cost of extra memory. This would also help for applications where
the allocation patterns don't mesh well with the assumptions of a
generational gc (where the worst case = our current gc), and leaves
the general performance of guile in a much better place than it is
right now.

> If someone gives us an incremental collector that's *more*
> efficient, I'm certainly not going to complain.

More efficient (generally) than a generational gc, or more efficient
than the current collector? The first doesn't seem likely, the later
is a definate possibility ;)

-- 
Greg