Tuning that was great in old JRockit versions might not be so good anymore

(This post is written by Mattis Castergren. Mattis is one of our Gurus in our Sustaining Engineering team)

Did you fine tune your JRockit application a few years ago? Did you search the web for command line options to shave off seconds in your favorite benchmark? In that case, I have a challenge for you.

Tuning a JVM for performance is hard work. Few programs are as complicated as a JVM. There are tons of more or less useful command line options and some of the knobs and dials you can manipulate will change some really arcane aspects of the run-time environment.

This is the reason why Out Of The Box performance (running with no tuning parameters) has been an important area for JRockit over the last years. What good is it to have a really fast JVM, if you can't tune it to its full potential? In a perfect world, an expertly tuned system and a system run without any command line options at all would give more or less the same performance.

So, how are we doing so far? Pretty good actually. The R27 line of JRockit has showed a big improvement in OOTB performance. Compared to the previous code line, R26, the OOTB performance has increased with over 100% on the specjbb2005 benchmark (see this)

One of several reasons was the re-write of how the command line options -XXtlaSize and -XXlargeObjectLimit works, which leads us to the topic of this blog post: "Tuning that was great in old JRockit versions might not be so good anymore"

In older versions of JRockit (basically, pre R27), increasing the TLA size was often a great way to increase performance. Wait a minute, you might think, what is the TLA size? That is not really important for this discussion, and many who tuned the TLA size did not really care. If you really want to know, read the first part of this

Setting a TLA size of 64k was used in some of our older benchmark submissions, and many happy system admins used the same flag to great success. But with JRockit R27, the way that XXtlaSize works changed. Before, there was only a fixed tla size. But with the new way things work the size is dynamic, and you tune it by setting a minimum and a preferred size.

This means that setting it to a fixed 64k size will actually limit the TLA sizing, which will often decrease performance and increase memory fragmentation. The once very useful JRockit tuning flag has become one of the most misused flags there is.

So, is there never a need for XXtlaSize? Sure there is, correctly used you might increase the score on your favorite benchmark by a few percent in some cases. But if used badly, you might find half of your Java heap to be lost due to memory fragmentation.

My suggestion is this: If you tuned your JRockit application some years ago and have recently upgraded to a newer version of JRockit, remove any X and XX flags used for tuning except Xmx, Xms, XgcPrio and XpauseTarget. Run some tests before and after, and don't be surprised if the OOTB performance is actually better than the old tuning.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today