Memory management in modern times

For us application programmers of modern times the canonical advice to memory management has been: don't do it. Runtimes, including virtual machines and operating systems, are tuned for the sort of memory traffic that normal programming patterns create. Trying to be too clever can lead to a serious degradation of performance, unless you are very careful.

So relying on memory management to do the right thing is nothing new when programming on JVM or other high level virtual environment. It was interesting to see a "bit twiddlers" take on the same subject.

www.varnish-cache.org/trac/wiki/ArchitectNotes

In the article Poul-Henning Kamp explains why writing your own caching mechanisms in modern operating systems is not a good idea. The result might be that data is bounced between main memory and disk, because neither caching system nor OS paging system has the total control over memory management.

Things got even more interesting when spotting these posts on JVM memory management.

java.dzone.com/terracotta_java_gc
java.dzone.com/terracotta-releases-bigmemory

Of course there is a commercial bias in what those guys are saying, but the basic message seems sound. The lesson feels first completely different: bypass JVM garbage collection and implement you own solution. Radical! But actually they are kind of saying the same thing: having two memory management schemes is bad. So you either have to rely on the underlying stuff, or bypass it completely and do it yourself.

The Terracotta posts also bring up the important issue of Java memory management not scaling up so well. It is not clear to me if this is an issue in the Java programming model or just an area where JVM garbace collectors need some further development and optimisation. Hopefully the latter, but we'll see.