BT

SGen: Mono’s Generational Garbage Collector

by Jonathan Allen on Jan 20, 2011 |

While Mono has in general been doing an admirable job of keeping up with .NET when it comes to APIs, there is one critical area where it is still far behind. The default garbage collector in Mono is the portable but inaccurate Boehm-Demers-Weiser conservative garbage collector. The main problem with the Boehm garbage collector is that it cannot accurately read registers and stack frames. Since it cannot determine if a given value is a pointer or a scalar, it always assumes that it is a pointer and marks the associated object as still alive. Not only can this incorrectly prevent large chunks of memory from being collected, it also makes compacting free space difficult.

SGen or “Simple Generational” is Mono’s new garbage collector. As the name implies, this two-year-old project is an attempt to replace Mono’s original garbage collector with a precise generational garbage collector similar to what we see in the .NET version of the CLR. The SGen garbage collector uses two generations instead of .NET’s three, but like .NET does have a separate heap for large objects.

Before Mono 2.10, which is still in preview, SGen was still very conservative. This new version adds support precise collection of managed stack frames, making it far less likely to encounter false positives. Unmanaged stack frames arising from p/invoke calls are still scanned conservatively.

Like .NET, SGen’s biggest weakness is pinned objects. If you pin an object in SGen’s nursery (think generation 0 in .NET), then it cannot completely clear out the nursery and memory becomes fragmented. The problem is actually worse in SGen for a couple of reasons. Not only are you dealing with fragmentation, it is fragmentation in the generation that SGen allocates memory from. Ideally all active objects are copied out of the nursery and it is reused whole cloth.

To compound matters SGen doesn’t just pay attention to explicit pins like .NET. As we mentioned before, the conservative scanning of unmanaged stack frames can cause objects to be pinned merely because there is a numeric value in the stack that happens to match a memory address in the nursery. Presumably this will be fixed in future versions as the pinning logic associated with p/invoke calls become more reliable.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great to see generational GC by peter lin

Things like GC take a lot of time and real world testing to get right. With patience, focus and an open mind, Mono should be able to produce a good generational GC. If one looks at JVM and .NET CLR, it "seems" to take about 4-6 years to produce a solid, reliable and performant generational GC. There's no short cuts, just lots of sweat and blood.

Is this a good or bad idea ??? by Miroslav Pokorny

Is it possible to have a area reserved for pinned objects, so they dont fragment the main 1st generation area ?

Re: Great to see generational GC by Srdan Srepfler

And patents.

Re: Is this a good or bad idea ??? by Jonathan Allen

The problem is that you don't know what objects are going to be pinned ahead of time. I guess you could move them into a special area when a pinning operator is started, but that could be very expensive. (Like a full GC cycle expensive.)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT