Re: My arguments

On Tue, Aug 12, 2003 at 01:21:33PM +0200, Fernando Diaz wrote:
> I have been made an study about the different techniques for a garbage
> collector for a month. 

I am interseted to know what questions you were studying.

When deciding whether or not I can write a piece of software with a
garbage collected system, I ask myself:

1) what is the worst case pause time for my expected heap size
2) what is the throughput of the collector when large amounts of
   memory are deallocated
3) how does the collector (and environment) interact with data
   accessable through modules written in C

Did you consider anything related to those questions?

> I think that Mono needs a collector that make the allocation process the
> simpliest it could be, then i refused the Mark-Sweep and Non-Copying
> Collection, because they have the problem of fragmentation what guide us
> to a complex allocator.

I think that the current libgc is "as simple as can be" because
someone else wrote it already. Writing another collector aught to have
much more aggressive goals than this to make it more useful than
libgc. 

I think the goal should be to help Mono come closer to the performance
of hand-coded C++. This means no pausing at all, even for really large
heaps. C++ already uses malloc(), so doing something similar is not a
problem.

> The same as Mark-Compact ocurrs in Copying Collection. The problem with
> them is that we need to rebuild the references to the objects after a
> collection, because the objects will me moved from their original
> location into the heap.

I don't understand. The objects are moved in both copying collection
and the compact phaze of mark-compact. Can you explain why you think
copying collectors are a problem while mark-compact are not?

> A generational adaptation of these algorithms would be good, it
> would make them more efficient. But an incremental adaptation would
> make them more complex and it would give them a few advantages.

When I'm writing a piece of useful interactive software (web-server,
client application), I will happily give up 30-50% of my CPU if I have
to, but I cannot accept uncontrolled pauses. That's why I'm happier
writing software in slow reference counted languages like Python, than
fast GC-pausing languages like Java.

Therefore, the collector must either be incremental (tri-color,
reference counted, etc..) or fully concurrent with the application.

If we're not going to achieve that, we might as well just keep using
libgc.

-- 
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