Re: My arguments

On Wed, Aug 13, 2003 at 03:44:29PM +1000, Fergus Henderson wrote:
> I don't agree.  For many applications we ought to be able to get
> significantly better performance than libgc using a good copying or
> mark/compact garbage collector. 

I'm not familiar enough with exactly how libgc works to know whether
this is the case or not, however, I'll take your word for it.

My point was that most applications I've worked with in the last
several years have problems with worst-case pause times long before
they have problems with memory usage or throughput. Memory is cheap
and CPUs are free, but pauses are often unacceptable. Obviously in
some environments (embedded, handheld, etc) this isn't the case.

> Also, there are advantages to using a type-accurate collector rather
> than a conservative collector (e.g. more predictable memory usage)
> which are desirable for some applications.  So type-accurate copying
> or compacting collection is desirable even if it is not incremental.

I agree there are advantages to a type-accurate collector. My
understanding is that libgc can be made aware of types to become more
type-aware and (effectively) less conservative. I think some of this
work has already been done for Mono. I could be misunderstanding
something as I have not seen the details. 

> Of course you are right that some other applications need incremental
> collection.  Different applications have different needs that can only
> be satisfied by different garbage collectors.  So the long-term plan
> should be to have several different garbage collectors, or at least
> several different GC strategies, and to provide application developers
> with some way of giving hints to the runtime about which GC to use.

We're in complete agreement here. Having a second collector
implementation would be good just because it would encourage Mono to
learn how to support multiple types of collectors. In this respect, I
encourage you to write your copying collector, and help Mono figure
out how to plug in other collectors.

> In the short to medium term, I think implementing a type-accurate
> collector and integrating it with the rest of the Mono implementation
> is already a complex task, so I think we should start off simple,
> e.g. with a straight-forward copying collector, and then worry about
> extending it to support generational collection, and only then worry
> about an incremental collector.  However, we should of course keep in
> mind while developing this the long-term goal of having support for
> multiple different collectors or collection strategies including at
> least one incremental collector.

This sounds like a good plan. I agree that before we can have some
type non-pausing collector we need to learn how to have more than one
collector.  Code on!

If anyone else is interested in doing a non-pausing collector, I'm
game to collaborate.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [email protected]
_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list