Garbagecollection in .NET has always rubbed me the wrong way. As aquick recap, garbage collection in .NET (as in Java) works bybasically halting the application and scanning all references fromthe root reference on. It then looks on its heap to determine thatevery object has someone else pointing to it, and if not the objectis freed (through a long process). The heap memory is thencompacted and any references are rebased. The program then restartsuntil garbage collection happens again at some point in the future.This means, for instance, that if you create a System.IO.Fileobject in a short method that opens a file in exclusivemode, and you fail to use the Dispose pattern or explicitlycall Dispose (Dispose being a sort of “garbage collection has somegaps, so here’s something that you can do to expedite at least partof the process”), the file will be locked until some unpredictablepoint in the future that garbage collection runs. You can, ofcourse, force garbage collection, but that throws off the entirelifecycle management and can cause other resource managementissues.
Ultimately it seems like the sort of solution that worksfor relatively small or isolated applications (where itworks admirably – for web apps and web services, isolatedservices, and relatively small Windows Forms apps .NET is afantastic technology, primarily insofar as it reducesdevelopment time), but not as a technology that scales up tolarge scale, highly responsive systems (where you want the loading,resource usage and response times to be predictable andconsistent). This case seemed to be somewhat proven by many of thedelays and issues with Longhorn (Windows Vista), and the backtrackingand reduced reliance on .NET as a system pervasive technology (TheRegister isn’t the most credible source, but it’s just a referenceto the sort of thing I’ve heard throughout the industry). Entirelypredictable.
One change that I would like to see added to .NET – optionalreference counted references, with a second heap specifically forclassic, fragmeted allocation. Reference counting, the oft malignedtechnology behind COM (mostly because people didn’t know how to use it properly),is a completely reliable and extremely predictable and usefultechnology in a completely managed environment for most uses (thereare exceptions where reference counting breaks, but you don’t haveto throw out the baby to clean the bathwater). Python, forinstance, 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, whencompiled, adds an automatic call to dispose when the object leavesthe scope. Not the same thing at all.