Sam Pointer

Introduction

I’ve spent quite some time tuning the performance of Java server applications in my last two roles. It helps that I had a great mentor (hello JJ if you are out there). For the past couple of months I’ve been increasingly involved in trouble-shooting and tuning performance problems with .NET applications. Being VM managed garbage collected runtimes both, many of the common problems and solutions I see for the JVM are also applicable to the .NET runtime. Here I present my Rosetta Stone for the JVM native looking to tune a .NET application. It isn’t a complete guide to .NET performance tuning (and I couldn’t write it if you need it - you could do a lot worse than reading this.), but it is enough to get the JVM native started for the most common subset of problems.

Garbage Collection Policy

Within most JVMs the default GC policy is "client", which keeps the memory footprint low and assumes relatively short-lived processes. It is therefore common to pass the -server switch to switch the trade-off within the garbage collector to better suit long-running process with generally larger heaps (I’ll ignore the existence of the new collectors in Java 6 for now). The .NET runtime behaves in exactly the same way, and also defaults to a "workstation" policy. This MSDN article details how to change the collector to the more agressive and threaded "server" collector.

Heap preallocation to ensure contiguous block of memory

It is a common trick to pre-allocate the JVM heap by setting the -Xmx and -Xms switches to the same value, thereby ensuring a contiguous allocation of memory and staving off any unexpected future allocation errors. This is not possible with the .NET 3.5 runtime, something I don’t understand given that arrays are allocated in contiguous blocks. I don’t think that the .NET runtime requires contiguous regions per-se, but the size and numbers of the assemblies being loaded (plus the aforementioned arrays) will require contiguous memory at some point. You should keep a careful eye on both the amount of free memory and its fragmentation.

GC and other performance counters

On the JVM we use the -verbose:gc and other related switches, or JMX, to monitor the JVM process and the important metrics, with .NET everything is most easily accessible through perfmon and the .NET counters. A little note on terminology, "pinned" objects are those that have active references and cannot be collected.