Monday, May 12, 2008

Memory - don't forget it hurts

I as a Java programmer have often wondered, don't long running programs/servers written in C/C++ have issues with memory allocation at all? I'm not talking about very special programs that you really wouldn't care writing in any language other than Assembly like - bit transferring or blitting or something low really level. I'm talking about medium to large scale applications with lots of business logic, decent concurrency requirements ... the kind of programs Java and .Net are used widely for.

It turns out that leaving memory allocation completely to the programmer is a pain in the backside. Without a managed runtime, any good engineering team using C/C++ ends up either developing their own memory allocator or buying one, because most of the allocators that come with the standard compiler kits have problems with scalability on multiple-cores/cpus/threads and over a period of time the heaps become fragmented.

And this is not just ordinary software - I'm talking about Video Games written in C/C++. It's interesting to read this - GameDevBlog: STL & Memory allocation on consoles and about efforts going on to make FireFox 3 better.

Now Java, on the other hand, which is supposedly (to the semi-ignorant folk) slow has a great choice of allocators - many of which work well on multicore platforms. The other advantage (depends on which way you look at it) is that fragmentation is less of a problem with "Copy collectors". And with the new Generational GCs rapid, consecutive allocation of temporary objects is actually very fast in Java. Plus there are other GC settings to choose from. Agreed, there is plenty of room for improvement - which is why Sun is working on the G1 Collector and let's not forget the Real-time JVM.

Before you go, here are a few more articles to read in your next coffee break. Just to understand how well Java's HotSpot has improved over the years:

# Java running faster than C

# Compiler Intrinsics