Tagged: Java Virtual Machine

Is Groovy back in fashion?


Last year I was taught “Object Orientated Design and Programming” as part of my Birkbeck MSc, using Groovy, a dynamic functional language built on top of Java and running on the Java VM.

I enjoyed it and liked Groovy – I went on to write some pieces of software for my MSc project using it.

But it also gave the impression of being a dying language and there were some complaints from fellow students who thought C# or Java itself would have been a better bet for them jobs wise (to which one of the lecturers responded with admirable chutzpah with a suggestion of using Lisp in the future).

This last week I have again been dabbling in Groovy and I get a sense that the language is suddenly back in fashion and its community of users seems more energy charged than a year ago.

Nothing scientific to back that feeling up with, just my judgement.

Related articles

More poor performance from the Open JVM?


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

Image via Wikipedia

My, expensive, and meant-to-be-fast server became available today and while I would not hesitate to recommend Hetzner – the people I ordered it from, the performance is disappointing.

I don’t think the issue is the box itself – it has 12 cores and 25 GB of RAM. Instead the issue seems to be the code – and I think that means the Open JVM (openjdk jre). If I specify 12 threads to run then performance falls to about 500% (ie the equiavlent of about five cores), if I specify 7 or 8 threads I seem to get peak performance at 600 – 700%. In other words I cannot get out of over a quarter of the silicon.

I think I need to install the Sun/Oracle JVM and see how that runs.

Related articles

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 0×1000000 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