Performance collapse in the Open JVM

Image via Wikipedia

Unfortunately, I do not have time to investigate this further myself, but others may do.

But yesterday I had a serious performance issue with the (open) JVM – though I was able to solve it with an algorithm change – swapping the problematic (integer) code for a lot of floating point maths: not the usual way to fix a performance issue but one that works.

My original code (in Groovy) appended many millions of integers to a list and then, once a loop was complete, calculated the average for the list (calculating the average working set size for a running process). When I was dealing with 2 – 3 million integers it worked well and performance, if anot exactly zipping along, was good. Push that up to 10 – 11 million and the first couple of times through the loop CPU utilisation dropped precepitatively (this was multithreaded – with runs through the loop operating in parallel) but the code was still visibly working but after that the intervals between loop completion grew to the point that the code seemed to have failed.

Even when I pre-allocated 0x1000000 items in what I now explicitly declared as an ArrayList the performance was little better – the first couple of iterations seemed a bit faster but performance then died.

I do not know what is going on – though excessive memory fragmentation perhaps coupled with poor garbage collection seem like the obvious answers: seems there is probably a brick wall for ArrayList size that sees whatever memory allocation algorithm operates inside the JVM fall over.

How did I fix it? Update the average in real time – in pseudo code below:

average = 0
previousInstructions = 0
loop [0, maxInstructions - 1)
{
currentInstructions++
if (change_in_working_set_size) {
average = ((average * previousInstructions) + workingSetSize() * (currentInstructions - previousInstructions))/currentInstructions
previousInstructions = currentInstructions
}
}

Like I say, floating point, but it works.

Java Performance Tuning

Related articles

• Twitter Shifting More Code to JVM, Citing Performance and Encapsulation (infoq.com)
• How Garbage Collection differs in the three big JVMs (dynatrace.com)
• Thomas Würthinger is a JVM hero (guidewiredevelopment.wordpress.com)
• Rhino is About to Get a Lot Faster (infoq.com)
• an experiment with generic arithmetic (blogs.sun.com)
• Not everything’s Groovy (usdlc.wordpress.com)
• Why OSCON Java? (radar.oreilly.com)
• Clojure: Lisp meets Java, with a side of Erlang (radar.oreilly.com)

Advertisement