Performance collapse in the Open JVM

Duke, the Java Mascot, in the waving pose. Duk...

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)
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

2 thoughts on “Performance collapse in the Open JVM

  1. Pingback: Need for speed | cartesian product

  2. Pingback: More poor performance from the Open JVM? | cartesian product

Comments are closed.