The Mindset

Many developers love to work in Java, .NET and other advanced development languages and platforms, because they think these environments free them from the need to take care of many unpleasant tasks, such as managing memory. Believe me when I say that I am all for it. I truly believe that using these development platforms enables the developer to concentrate on the important stuff: developing more value. Spending hours, if not days, trying to find illusive memory leaks, memory corruptions, etc. is frustrating and far from being productive.

But can we really trust our advanced platforms? Do they always behave as expected and take care of our resources? As you might guess, the answer is no. Their most highly regarded feature, garbage collection, sometimes fail to provide us we what we expect of it.

Have a look at these three examples I found in an arbitrary Web search. Although all of them apply to .NET, it is not hard to find similar problems with Java. The bottom line is that when you write your code in a high level managed language, you still depend on code which had to "manually" manipulate memory. It might be a component you use, a graphical widget or the virtual machine running your application. At least some of these external entities might cause you a terrible headache when your customer calls and reports the application has crashed, only to find out it is a memory leak that caused it.

So, what can you do about it? Should we throw away these great languages and platforms and go back to doing all the gory stuff ourselves? I believe we shouldn’t. Java and .NET are currently irreplaceable. They are the best choice for developing enterprise applications in a Web enabled environment. Either way you look at it, the chances for you to come across a memory-related problem in Java and .NET is by far smaller than the chances for such a problem in C++ code. However, this does not mean you should blindly trust your platform and the components you use. Now that you know that the "unexpected" can happen, you should take some protective measures when you develop your .NET or Java product.

The first is to use a memory profiler from the first day of development. Don’t wait until you have to deliver the product to find out that some component you use causes a memory leak. By that time it might be too expensive to replace with another.

The second thing is to do some research before using a component (or part of your platform). A simple search on any of the components mentioned in the examples above would have provided you an alert on time.

Lastly, if you can isolate a component you do not control using common design techniques, such that it would be possible to easily replace it as needed, you will be able to sleep better at night. Of course, this last point is not always possible to achieve (especially when the problematic components are essential parts of the platform you use), but in many cases this is a reasonable goal.

So, can you trust your Garbage Collector? Well, probably as much as you can trust any piece of code you didn’t write. Don’t mislead yourself to believe your memory management problems are over just because you write in Java or .NET. Be alert and take reasonable actions to ensure you wouldn’t be surprised.