Garbage collection in .NET has always rubbed me the wrong way. As a quick recap, garbage collection in .NET (as in Java) works by basically halting the application and scanning all references from the root reference on. It then looks on its heap to determine that every object has someone else pointing to it, and if not the object is freed (through a long process). The heap memory is then compacted and any references are rebased. The program then restarts until garbage collection happens again at some point in the future. This means, for instance, that if you create a System.IO.File object in a short method that opens a file in exclusive mode, and you fail to use the Dispose pattern or explicitly call Dispose (Dispose being a sort of "garbage collection has some gaps, so here's something that you can do to expedite at least part of the process"), the file will be locked until some unpredictable point in the future that garbage collection runs. You can, of course, force garbage collection, but that throws off the entire lifecycle management and can cause other resource management issues.

Ultimately it seems like the sort of solution that works for relatively small or isolated applications (where it works admirably - for web apps and web services, isolated services, and relatively small Windows Forms apps .NET is a fantastic technology, primarily insofar as it reduces development time), but not as a technology that scales up to large scale, highly responsive systems (where you want the loading, resource usage and response times to be predictable and consistent). This case seemed to be somewhat proven by many of the delays and issues with Longhorn (Windows Vista), and the backtracking and reduced reliance on .NET as a system pervasive technology (The Register isn't the most credible source, but it's just a reference to the sort of thing I've heard throughout the industry). Entirely predictable.

One change that I would like to see added to .NET - optional reference counted references, with a second heap specifically for classic, fragmeted allocation. Reference counting, the oft maligned technology behind COM (mostly because people didn't know how to use it properly), is a completely reliable and extremely predictable and useful technology in a completely managed environment for most uses (there are exceptions where reference counting breaks, but you don't have to throw out the baby to clean the bathwater). Python, for instance, works largely based upon reference counting.

Some might note that Visual C++ 2005 has added "stack" reference types. This really is a bit of syntactical sugar - basically it's just a variant of the Dispose pattern that, when compiled, adds an automatic call to dispose when the object leaves the scope. Not the same thing at all.