Gen GC release target

[peger]

Hi, was wondering if anybody knows what the release target is for the generational GC into mainline Mono? With ASP.NET supported and the JIT drastically improved in 2.0 / 2.next, the current GC seems to be the only thing holding us back for some of our (garbage heavy) ASP.NET apps. Any guess would be a help too! :-)

Additionally, every though of cannibalizing some other project, say OpenJDK? They've definitely got more than an few production-ready GCs, though i'm not sure about licensing...

Regards & TIA

[Paolo Molaro-2]

On 10/09/08 peger wrote:
> Hi, was wondering if anybody knows what the release target is for the
> generational GC into mainline Mono? With ASP.NET supported and the JIT
> drastically improved in 2.0 / 2.next, the current GC seems to be the only
> thing holding us back for some of our (garbage heavy) ASP.NET apps. Any
> guess would be a help too! :-)

Mono 1.9/2.0 have already a few GC speedups.
After 2.2 we'll work on integrating the new GC in the default build.
The release where it will actually be a default will depend on how
well it will behave in the real world (many apps that currently
depend on a non-moving GC will likely break, so it will take time
to fix them, too). We hope for 2.4, but it may happen for 2.6 or later
if there are many problems (boehm GC took years to stabilize after it
was used inside mono).

> Additionally, every though of cannibalizing some other project, say OpenJDK?
> They've definitely got more than an few production-ready GCs, though i'm not
> sure about licensing...

GCs implemented for other systems are basically useless, even if they
have a compatible license (which openjdk doesn't).
One reason is that the a lot of effort is in changing the JIT and the
runtime to support a moving GC, something like openjdk's GC would
increase this effort, since it has different requirements and a much more
complex interface.
Another is that those GCs may be unable or may be completely untuned
for patterns we must implement (pinning, for example).
In some other cases, they don't support things like value types and
managed pointers (again openjdk).
Then there are other issues: we don't want a GC that takes twice as much
memory as the current one (see the shootout results for examples).
Besides openjdk, I'm not sure there is actually any production-ready
GC around that has at least some of the features needed by mono.

lupus

--
-----------------------------------------------------------------
lupus@...                                     debian/rules
lupus@...                             Monkeys do it better
_______________________________________________
Mono-gc-list maillist  -  Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list