Chris Brumme posted some interesting stuff about garbage collection in the next version of the .Net runtime. This article, plus some others that are floating around the net, provide a lot of detail about the workings of .Net's memory management. Note that I'm reading this from the perspective of a person most familiar with Java and its runtime.

The .Net runtime seems to implement a mark and sweep GC scheme, but where classes are marked as collectable by presence in a system RegisteredForFinalization queue. Of particular interest, because objects must be explicitly registered for collection, not all objects are checked for finalization. A finalizable object and any object reachable from it, is added to a ReadyToFinalize queue. So an object need not be registered as finalizable to be garbage collected. I find this aspect of .Net GC fascinating, and I'd like to think about it some more. I'm assuming that, rather than a design decision, this was a requirement due to .Net's language neutrality and language mixing at runtime.

Chris also strongly suggests not touching other finalizable objects in a finalizer. This, plus the act of registering objects as collectable reminds me of the memory management scheme in the Objective C runtime in MacOS X. Of course, MacOS X allows you to allocate objects out of any number of pools, each backed by some different scheme; I'm not sure how .Net links object allocation and deallocation.

If not all objects are automatically reference-counted, it suggests that the .Net developer has greater control over, but bears a greater burden for, memory management. Given .Net's focus on component and service orientation, this seems like a bit of a problem. It is rather difficult to manage component-level services from within a component that may be embedded in another, distributed across runtimes, etc... But this is a difficult problem to solve in any scheme.

One thing I like about the .Net garbage collection is that finalizers seem more likely to be called than Java's finalizers. It seems that if the process terminates normally, the ready to finalize queue is processed. This is nice; Java's whimsical garbage collection is one reason few people put meaningful code in the finalize() method.

I'd like to do some more reading about how GC and object allocation are related, and about how .Net's GC scheme deals with weak handles. But it certainly is fascinating to have so much information about code still in development.