The business of garbage collection
Tony Soprano was the King of trash collection in northern New Jersey, and it seems Mafia always get involved in hauling garbage, but there's still room for a high tech business not related to crime.
A few months ago the new G1 Garbage Collector was released for the sake of Java developers. G1 is a low-latency, low-pause garbage collection system that improves performance for Java applications. The new G1 also offers a feature that was available for .NET developers since 1.1: the ability to compact memory: move the used blocks together to avoid fragmentation.
The new G1 can only be used in production by developers who have signed (and paid) the Sun's support contract, which means Sun (probably under the new Oracle's vision) is opening a business in garbage collection.
Why garbage collection is important
Modern platforms like Java and .NET share a number of features that locates them a few steps ahead from previous environments like their C/C++ ancestor. To mention a few:
- An extensive class library: almost everything you need for development is already covered by the standard library in Java or .NET. No need to code your own collections, thread management, queues, string handling and so on. Classes to deal with the most common (and not so common) situations are already there. In .NET, network communication was simplified since version 1 by Remoting, and the same was true in Java with RMI (Remoting was later replaced by WCF, but that's a different story).
- A simple and yet powerful language: C# and Java are the main language for the .NET and Java platforms, despite both allow many other languages to play together.
- An improved ability to deal with libraries: both Java and .NET make dynamic package loading (assemblies in .NET terms) a snap, together with strong versioning and so on, something a little bit harder on previous platforms.
And the first and foremost: they both release developers from freeing memory, the single most important source of errors with C/C++! While it is a good idea or not to shield developers from knowing "what's going on with memory" it's an entire topic itself, but it seems it is much easier to train someone to develop software when memory release concerns are not present.
And "memory magic", one of the cornerstones of Java and .NET (and of course Mono, the open source .NET implementation) is achieved through garbage collectors.
Good garbage collectors will not only free developers from the "freeing burden" (and hence of a good number of memory-leaks, although not all of them) but also will solve the interesting problem of "memory fragmentation" (despite of the overall amount of free memory, there's no contiguous free mem. to allocate a given object), which will most likely only affect "memory intensive" and long running processes, typically server side ones. Only "compacting" collectors (like the .NET's and G1 ones) will be able to solve this situation.
Not being able to explicitly control how memory is freed (you're still in control of how you reserve it by creating objects) has some drawbacks that will most likely show up when you're developing heavy-load server software (although probably remain hidden in other scenarios): your system can consume much more memory than what you designed it to use because it is not being freed at the same pace it would be on a C/C++ application.
So the garbage collector can be seen as a really key piece of the "software engine" making both Java and .NET platforms run. Sometimes the application will need the GC to solve the fragmentation problem, sometimes it will need it to be fast enough so it can run almost at efficiently (memory-wise) as a "native" counterpart, sometimes the "GC strategy" will need to use as much memory as possible to reduce the "collection impact" and improve overall software performance.
GC business opportunities
When you're writing a "hello world" app. the defaults are always ok. But then you move into more "serious" stuff and then you hit against the defaults instead of taking advantage of them.
It's clear that native (C/C++) programming comes at a cost, and nowadays there're still systems that will benefit from non-managed implementations. But many (including myself) think that Java/C# productivity is much better than what you can achieve with ancient language/platform combinations, and one of the issues to solve is make them as memory efficient as possible.
And then is where the GC business enters the scene: I'll be obviously missing some points, but I think long-running, memory-demanding server software will be the one to benefit from specific GCs which can be tuned by the application (or SYSADM) on different scenarios.
G1 introduces some new features not available for the Java framework before and also some tuning. The same is true for .NET: different "profiles" (including a "server" one, which not only stops threads differently but allows the process to eat much more memory hence reducing GCs and improving performance) can be configured to finely tune application performance.
While I'm not sure Microsoft will allow third parties to develop GCs, I see a clear opportunity in the Java world (both IBM and Sun have already released GCs) and more specifically on the Mono framework.
Mono is a very interesting case since it opens up the .NET framework for cross-platform development. While always maturing, it is already mature enough to be used to deploy C# software on Linux, Mac OS X and even Solaris, and I think it will only achieve its full potential when all the available Unix flavors get supported.
That being said, Mono implements a weaker GC than the Java and .NET counterparts. The Mono GC is heavily based on the aging libgc library, first written more than a decade ago. Libgc makes the Mono GC unable to precisely track memory usage under certain circumstances due to design limitations, and also because internal Mono runtime structures are not used for precisely memory tracking by the library.
Hopefully the sgen collector is being developed to replace the older one, featuring interesting abilities like compacting.
Obviously new GC trends will greatly benefit Mono written applications, strongly leveraging the whole platform and positioning together with the .NET and Java counterparts.