Re: gc notes available

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

Mikael Djurfeldt <mdj@nada.kth.se> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > I've put my generational gc notes on my web site at
> > http://home.thezone.net/~gharvey/guile/ggc-notes.txt
> > 
> > It's a (too long) look at most of the ideas I've come up with to
> > approach implementing a gen gc for guile. Feedback & pointing out of
> > really stupid ideas is welcome.
> 
> I've just downloaded the text, and I'm not sure when I'll get time to
> study it for real, but there is one thing which I reacted to directly:
> 
>   1) Incremental collection. I've not given this a whole lot of thought,
>      and I don't know that there's enough call for guile as a real-time
>      system to make this worth the effort and performance cost.
> 
> This sounds a bit backward to me.  I think that, for many users,
> incremental collection is even more important than generational GC.
> 
> In these days of multimedia, when user interfaces tends to be fancier
> and fancier, real-time performance gets more and more important.

I was thinking more along the lines of hard real-time (you'd better
read from device foo within x usecs, or 6 months worth of simulation
is now junk), rather than the case of an interactive system, which
really wants more of a 'don't interrupt me when it's noticable, or at
the very least don't do it often' assurance. I'm thinking that smart
scheduling can work just as well in that case, and an application that
really needs that sort of behavior while generating lots of garbage
could live with a larger heap space when it needs to assure that a
collection doesn't happen. I would expect the increased memory
requirements in this case wouldn't be too much more than the amount of
garbage that will live longer in the incremental version. Maybe
something like

(without-gc
	(push-frames))

or even
(with-cheap-gc
	(push-frames))

Where this will only consider very cheap collections.

> 
> Just look at how many Java-applets which displays animations on the
> net.  How is Guile going to compete with that if animations are
> intermittently stopped due to GC?  (I know what I'm talking about
> because I've tried to implement games in Guile. :)

Well, if the computer can run java quick and spiffy, gc times are
probably not going to be that noticable (actually, in that case, even
the current gc probably isn't that bad), and if we are allowed java
constraints, we can eat resources like candy. I was under the
impression that applications in this category would be optimized
against creating unnecessary garbage in the intense bits (I've been
meaning to take a close look at the abuse code, though they didn't
really have the constraints of guile), so generally a gc shouldn't
happen there. (of course, I'm not too tied to this, since a
time-critical thread and a major garbage thread blow it out of the
water ;).

But isn't that web stuff usually animated gifs? 

> I remember that this was one of the important points that people
> stressed when Jim visited Japan some time ago.
> 
> Also, I'm not so sure that it has to cost a lot.

It doesn't necessarily have to cost a lot, although it does mean a few
more bits per object, which is what I've been trying to minimize while
thinking about the gc (I broke down and abandoned the byte, but I'd
like to avoid going larger than 2). It does cost more (possibly many
more) calculations per object traced, but that shouldn't be noticable
from an application point of view, except in the additional dead
objects that hang around for a bit longer.

My thinking is that the (hopefully :) greatly reduced gc run times and
a bit of smart scheduling + allowing gc disabling in time critical
bits will make it a non-issue for the most part (it shouldn't be much
more of a factor than switching with other programs on the os).

-- 
Greg