[Mono-dev] Status of Mono Garbage Collector?

Paolo Molaro lupus at ximian.com
Thu Mar 2 10:21:45 EST 2006

On 03/01/06 Hubert FONGARNAND wrote:
> I'd want to know more about the statut of this new GC. I think, that
> mono will be usable (on a desktop) (try to use beagle...) only if
> there's a good precise GC... 

You're completely wrong. First, if there is a leak it is most likely not
the GC's fault. Of the many excessive memory usage cases I debugged the
issue was:
*) most of the time a bug in some p/invoke binding (40%)
*) very often the user or a library call made 100 allocations when just
one was needed (40%)
*) sometines a leak inside mono (10%)
*) excessive memory retention by the GC (10%)

Whining about the GC has been one of the preferred sports of people
who wanted to avoid fixing the major issues. So the GC gets the blame.
A new GC can't fix the bugs in the bindings or cover for bad programming
practices. So, start fixing those issues: the new GC will happen faster
and you will see more of the improvements it'll make.
Let's say the new GC will be 50% better than the old one. This means
that we solved 5% of the overall issues.
Fix half of the binding issues or the code issues and you'll have improved
by 20%. Simple eh?

That said: mono and many of the libraries are perfectly usable on the
desktop now and have been for a long time. Some issues still exist, of
course: file detailed bugs about them and we'll be quicker at fixing
them (or post a patch...).

> There's too many memory leak problems with
> the current boehm GC... (even on a server, i must restart apache once a
> week to avoid memory problem). 

This depends on the app: file a bug report with a test cases that shows
the issue. Many apps run just fine for weeks.

And yes, the new GC is progressing, but it will happen faster if you
help out fixing bugs, improving the runtime and the mono assemblies
and the bindings.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list