How bizarre.
 
Next time we will look at how these final variables actually get captured/cloned into the inner classes.  One might be surprised what is happening at the bytecode level to allow these 'final' values [to be?] made available to inner classes

I'm not asking you this because I want to know if you have intimate knowledge of the JRE (although if you can keep bits of trivia like this in your head, I am truly impressed).  My question really comes out of the world of performance analysis of Java runtimes.  Suffice it to say that as the Java Labs works to improve JRE performance, sometimes our analysis leads to improvements that can be realized by tuning these existing command-line flags.  But here's my theory...I bet most of you use few, if any, of these flags in production.  You probably have very good reasons for doing this.  You may not have access to the command line, or you may have different applications, some of which my benefit from certain flags, while others won't.  If true, the result is the same...when we look to improve JRE performance, we really need to do it in a way that is engineered to help potentially any application in a flexible way that does not require changes to the command line.

So answer these two questions:

• Do you set any command line flags in production?
• If yes, what are they?

Let us know what you think.

enum LIGHT { RED, AMBER, GREEN}; 
Here we  are defining an enum that we can use to hold the state of a traffic light. The above code allows LIGHT to be used as a new type.
LIGHT light = LIGHT.RED;
and via some magic we can use LIGHT values in switch constructs.
switch(light){
   case RED:
       System.out.println("Stop");
       break;
   case AMBER:
       System.out.println("Get ready");
       break;
   case GREEN:
       System.out.println("Go");
       break;
}
we can iterate over the values of LIGHT using the array returned from the values() accessor..
 
for (LIGHT light:LIGHT.values()){
    System.out.println(light);
}

and can also perform ordinal comparisons..
if (light < LIGHT.GREEN.ordinal()){
   System.out.println("Not yet!");
}

Because enums are indeed Classes we can customize them by adding fields, constructors and methods. 

So if we wanted to be able to query each 'value' for the next in the sequence (including wrapping from GREEN to RED) we can use  :- 

current.values()[(current.ordinal()+1)%current.values().length]

However, rather than having this logic spill out into the code using the enum, we can provide a method in the enum itself 

enum LIGHT {
   RED, AMBER, GREEN;

   LIGHT next(){
       return(values()[(this.ordinal()+1)%values().length]);
   }   
} 

So now we can query the next value using

light = light.next();

We can also overload methods for each value. So an alternative to the above implementation might be 

enum LIGHT {
   RED,
   AMBER{
      LIGHT next(){
         return(GREEN);
      }
   },
   GREEN{
      LIGHT next(){
         return(RED);
      }
   },
   // We need a method to override, so lets assume RED is the default
   LIGHT next(){
       return(AMBER);
   }   
}

Which is a little more verbose, but in some ways more explicit.  Note that we must provide an implementation for the enum and then each 'value' can overload this if it chooses.

Although we can't extend enums (and probably for good reason) we can implement interfaces.

Let’s say we had an application which deals with a bound set of file types (XML, TEXT and ANY). We could make a FILE_TYPE enum which supports the FileFilter interface.

enum FILE_TYPE implements FileFilter  {
   ANY,
   TXT{
      boolean accepts(File _file){
         return(_file.getName().endsWith(".txt") || _file.getName().endsWith(".text"));
      }
      String getDescription(){
         return("TXT files");
      }
   }
   XML{
      boolean accepts(File _file){
         return(_file.getName().endsWith(".xml"));
      }
      String getDescription(){
         return("XML files");
      }
   }
   boolean accepts(File _file){
      return(true);
   }
   String getDescription(){
      return("Any file");
   }
}

This then allows us to write a method for getting a file from a JFileChooser dialog... 

File getFile(FILE_TYPE _fileType){
 JFileChooser chooser = new JFileChooser();
 filter.setDescription(_fileType.getDescription());
 chooser.setFileFilter(_fileType);
 int returnVal = chooser.showOpenDialog(parent);
 if(returnVal == JFileChooser.APPROVE_OPTION) {
    return(chooser.getSelectedFile());
 }
 return(null);
}

So we can ask for an XML file using..

File file = getFile(FILE_TYPE.XML);

Obviously we need to be careful and not 'misuse' them, but I believe that enums can offer options beyond the traditional static list of values.

Many thanks to the Java Posse for the opportunity.

Ben

When the script is complete and debugged, however, you may find it more convenient to run JMeter in non-GUI mode.  Because of the reduced overhead, you may also find you can drive more requests per second out of JMeter in non-GUI mode.  Running a finished test plan in non-GUI mode is fairly simple, use the -n option for non-GUI mode and the -t option to specify the test plan as follows:

      JMeter -n -t MyTestPlan.jmx

However, if you take an existing test plan you developed in GUI mode and run it as above, chances are the only output you'll see will be something like the following:

Created the tree successfully using MyTestPlan.jmx
Starting the test @ Mon Mar 02 14:01:13 CST 2009 (1236024073938)
Tidying up ...    @ Mon Mar 02 14:01:15 CST 2009 (1236024075844)
... end of run

with no additional information sent to stdout.  Any listeners you happened to have in your test plan were probably GUI-mode-specific and don't send anything to non-GUI mode.  So how do we see how we're doing regarding throughput and/or response time?

Using the JMeter Summariser

The Summariser is like a special listener that only applies to non-GUI mode.    It is controlled through JMeter properties.  JMeter properties can be set either by

• editing the default in the bin/JMeter.properties file
• creating a new properties file and specifycing that on the JMeter command line (-p option)
• specifying any number of individual properties on the JMeter command line using the -J or -D options (type JMeter -help to see the command line options).

The following properties affect the summariser:

# Define the following property to automatically start a summariser
# with that name(applies to non-GUI mode ony)
summariser.name=summary
#
# interval between summaries (in seconds) default 3 minutes
summariser.interval=180
#
# Write messages to log file
summariser.log=true
#
# Write messages to System.out
summariser.out=true

So with the above properties enabled, we would get a summary sent every 180 seconds to both System.out and the log file.  Note the summariser.name allows other summarisers to be developed and plugged in but I have not investigated that yet.  The default summariser has been pretty useful.  Here's an example of what you get from the default summariser:

summary +    41 in  15.4s =    2.7/s Avg:  2234 Min:   383 Max:  6974 Err:     0 (0.00%)

summary +    57 in  21.5s =    2.6/s Avg:  2548 Min:   618 Max:  4528 Err:     0 (0.00%)

summary =    98 in  32.5s =    3.0/s Avg:  2416 Min:   383 Max:  6974 Err:     0 (0.00%)

summary +   108 in  21.8s =    5.0/s Avg:  1291 Min:   229 Max:  6317 Err:     0 (0.00%)

summary =   206 in  52.5s =    3.9/s Avg:  1827 Min:   229 Max:  6974 Err:     0 (0.00%)

The lines with "summary +" are incremental for the latest summariser period, the lines with "summary =" are cumulative.  The above was with a summariser period of 20 secs, you can see the actual periods can sometimes be longer than the specified period and the length of the very first period is somewhat random.  You get the throughput statistics as well as average, min and max response times, and how many errors were detected (assuming your JMeter test plan as assertions to detect errors).

The JMeter log file

You may have noticed that one of the summariser properties was whether we wanted to send summariser output to the log file.  Every JMeter run produces a log file, by default bin/JMeter.log.   In either GUI or non-GUI mode, you can specify a different log file directly on the command line using the -j option.  And as with most things in JMeter, the actual name of the log file is configurable through a property, in this case the log_file property.  One interesting option allows the log_file property to include the date, such as

log_file='JMeter_'yyyyMMddHHmmss'.tmp'

So when you enable summariser.log=true as we did above, the summary lines we saw on stdout will also appear in the log file, with an identifying header such as "INFO  - JMeter.reporters.Summariser:" to show their source (they will be mixed with other JMeter log information).

Logging samples in non-GUI mode

Note that the JMeter usage message refers to a different kind of log file which can be used to log the actual samples in an xml file format called JTL:

       -l, --logfile <argument>

              the file to log samples to

So in non-GUI mode this can be used to log the actual sample information much as the View Results Tree listener does in GUI mode.  In fact, you can take the jtl file produced here and load it into the listeners in GUI mode to get a more readable display.  Because of the intrusive overhead of logging all samples, you probably won't want to do that in measurement mode but you might do it when debugging a problem.

In a future post, we'll get into a couple of other useful JMeter topics:

• Using the scripting configuration elements supported by JMeter to add dynamic run time information to the log file.
• Having finer control over what gets saved in the .jtl file

Meanwhile, I'd be interested in learning how others use JMeter in non-GUI mode.

All of this adds up to inaccurate mappings between X86 assembly and performance counters which can mislead most performance engineers into fixing performance bottlenecks on the wrong sequence of code. 

One way around this is to use better implementations of hardware performance counters.  The latest AMD Opteron™ processors have something that can help.  Instruction Based Sampling (IBS) provides precise information about the execution of instructions.  IBS provides four advantages over conventional performance counters:

1.     Hardware events are attributed precisely to the instruction that caused the event.

2.     A wide range of events are gathered, and are not limited to four out of many events that must be specified at the beginning of the profile.  

3.      Virtual and physical addresses of load/store operands are collected.  This allows managed environments to associate specific data structures with X86 instructions.

4.     Latency is measured for key performance parameters such as data cache miss.

For more information about IBS, see the AMD Software Optimization guide for AMD Family 10h Processors.

Things like code refactorings, insufficient code coverage testing, poor coding standards or mere oversight can often lead to redundant code. Generally all commercial JVMs apply a certain level of escape analysis and dead code elimination optimizations while executing Java code. However, there are certain cases where JVM is unable to eliminate redundancy; for example, unused instance variables of a class.

IDEs such as Eclipse can warn the Developers about local variables and instance variables not being read by the program. It might be easier for JVMs to identify and optimize away redundant local variables. However, it would not be possible for a JVM to eliminate unused instance variables that can potentially be accessed using mechanisms such as Java Reflection. These unused instance variables will increase object size and, in turn, the memory footprint of the Java application if a large number of such objects are allocated by the program.

You might think that such unused/unread instance variables might not have a big impact on the application performance. Contrary to this belief, such redundant variables can substantially affect application performance. In fact, this could lead to pathological cases where application performance can be hampered due to inefficient processor memory cache usage. For example, a redundant instance variable which gets mapped to the end of object layout in the memory can increase the object size such that the resulting object does not fit into a single cache line. On the other hand, when such a field gets mapped into middle parts of the object layout, it can lead to memory holes and result in redundant garbage collection cost.

The following benchmark demonstrates performance effects of unused instance variables:

import java.util.LinkedList;

public final class ObjectTrimming {

      private long redundantField1 = 0L;

      private long redundantField2 = 0L;

      private long redundantField3 = 0L;

      private long redundantField4 = 0L;

      private long redundantField5 = 0L;

      private long redundantField6 = 0L;

      private long redundantField7 = 0L;

      private byte[] usedField = null;

      private ObjectTrimming(){

            usedField = new byte[968];

      }

      public static void main(String[] args) throws Exception {

            LinkedList listStore = new LinkedList();

            long totalTime = 0L;

            for(int j=0; j<10;j++)

            {

                  long then = System.currentTimeMillis();

                  for(int i=0; i< 104857; i++)

                  {

                        listStore.addLast(new ObjectTrimming());

                  }

                  long now = System.currentTimeMillis();      

                  totalTime += now - then;

                  System.out.println("After Iteration " +j + " total number of elements in the Linked List: " +listStore.size());

            }

            System.out.println("Execution Time: " + totalTime);

      }

}

As you can see, this application creates approximately 1024M of data. The ObjectTrimming class has 7 fields of long data type and a byte array. Since each long field occupies 64 bits of data, objects of type ObjectTrimming class will have 56 bytes of space occupied by long fields. We are using the byte array to allocate another 968 bytes of data which will bring each ObjectTrimming object to a size of 1KB. We are creating 104857 such objects in a loop which iterates for 10 times. Thus in the end, listStore linked list will contain approximately 1024M of data.

We executed this benchmark three times on a system with configuration of 2 chips, 8 CPUs, 4 cores per chip AMD Opteron 8384 processor running at 2.7GHz, with 8G of RAM and it took an average of 9894 milliseconds. None of the long variables are used by the ObjectTrimming class.    Neither could they be accessed by other classes, so we decided to remove these fields and rerun the modified benchmark. This time the execution time for the three runs averaged to 6493 milliseconds. That is 52% improvement in application performance. It is unlikely that a class will have a large unused-fields-to-used-fields ratio as in our example above. However, the example above shows that saving 56 bytes of data in a 1K object can have a big impact on memory footprint of the application.

We used Sun Java SE Runtime Environment (build 1.6.0_06-p-b01) with Java HotSpot Server VM (build 14.0-b09, mixed mode) for the above experiments. The JVM command-line flags used to run the benchmark were: java -server -Xms1175M -Xmx1175M

As noted above, JVMs cannot necessarily eliminate such unused fields, thus it is the Java Developer's responsibility to optimally define classes.

From Wikipedia(http://en.wikipedia.org/wiki/Immutable_object) we get the following definition:-

 'In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.'

I like this definition as it describes what I had assumed to be the main point: that an instance's state should not be allowed to be modified post-construction.

However, I recently found myself looking at the String class and came across its hashCode() method :-

public int hashCode() {
 int h = hash; 
 if (h == 0) {
     int off = offset;
     char val[] = value;
     int len = count;
       for (int i = 0; i < len; i++) {
           h = 31*h + val[off++];
       }
       hash = h;
    }
    return h;
}

Looking closely we see that this is a classic implementation of the 'lazy evaluation' pattern. Rather than computing the hash value in the constructor, or computing it each time the hashCode() method is called,we compute it once (on the first call to hashCode()) and save the computed value in the hash field.

We can see this if we read the private hash field reflectively.

String helloWorld = "helloWorld";

Field field=String.class.getDeclaredField("hash");
field.setAccessible(true); // because hash field is private

System.out.println("Before first hashcode call "+field.getInt(helloWorld));

helloWorld.hashCode();

System.out.println("After first hashcode call "+field.getInt(helloWorld));

If one runs this snippet of code it will output something like

Before first hashcode call 0
After first hashcode call -1554135584

So for a String instance which we create, but for which we never call hashCode(), the private hash field will remain 0. It is only changed when we call hashCode().

By Wikipedia's definition I believe String fails the immutablility test.

The argument might be that we can't observe a String instance in a different state without resorting to a reflective read of String's hash field and because the call to retrieve the state actually modifies it; if we can't observe it changing, then it didn't change.

This is reminiscent of

"If a tree falls in a forest and nobody hears it, did it make a noise?"

Or my personal version

"If I say something in a room and my wife doesn't hear me, am I still wrong?"

However it still seems like String is not immutable.

In Eric Lippert's blog (http://blogs.msdn.com/ericlippert/archive/2007/11/13/immutability-in-c-part-one-kinds-of-immutability.aspx) he refers to this as 'Popsicle Immutability' and although it seems safe, (ignoring reflective access) it does seem incorrect.

So I would like to open up a discussion:  Is String immutable?

The easiest way to set your heap would be to set a maximum allowable size and let the JVM handle everything else.  By using the flag "-Xmx" you can set the heap size.  Example would be:  "-Xmx1024m" or "-Xmx1g" both set the maximum heap size to 1gigabyte.  Just realize that you don't want to set the maximum heap larger than the available memory in your system.  Performance will suffer and you'll be worse off than had you used a smaller heap.

While that's a good start, we can clearly do better than that.  The JVM also has this notion of the heap being split in multiple sections.  One section is the nursery or young generation where all allocations happen.  The other section is the tenured space or old generation where long lived objects get promoted from the nursery.  We can tune the size of these spaces for better performance depending on how our application allocates objects.  By adding the flag "-Xmn" you can set the nursery size, and the remaining heap is then allocated to the tenured space. 

This tuning of nursery can be an important source of performance improvements as a nursery collection is significantly faster than a full GC.  And if your application creates many short lived objects then you would be better off with a larger nursery than tenured space.  If only we could somehow calculate how much nursery our application uses we could tune better.  Ah, but we can!  Just use the flag "-verbose:gc" which shows each nursery and full GC and how much was collected and how much of the heap is free.  And in our case we'll add "-XX:+PrintGCDetails" which increases the level of detail.  As an example see:
 
[GC [DefNew: 910K->12K(960K), 0.0003947 secs] 1239K->341K(5056K), 0.0005048 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC [DefNew: 908K->13K(960K), 0.0004003 secs] 1237K->341K(5056K), 0.0005126 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC [DefNew: 909K->14K(960K), 0.0005241 secs] 1237K->342K(5056K), 0.0006367 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC [Tenured: 3485K->4095K(4096K), 0.1745373 secs] 61244K->7418K(63104K), [Perm : 10756K->10756K(12288K)], 0.1762129 secs] [Times: user=0.19 sys=0.00, real=0.19 secs]

Those are examples of the output you'll get when using "-verbose:gc" and "-XX:+PrintGCDetails".  What does all of that mean?  The first three lines are young generation collections.  The Nursery is 960k large and had around 909k worth of data before the collection and around 13k after the collection.  The total size of the young generation was 5056k and had around 1237k worth of data before the collection and about 341k after the collection.  The last line shows a full collection.  The tenured space is 4096k and in this case objects were moved into tenured space but none were collected.  This points to a bigger problem, where the tenured space is too small and should be increased to help give better performance.
 
You might have noticed that with "-XX:+PrintGCDetails" you'll get a bit of output when your application ends that looks like:
 
Heap
 def new generation   total 960K, used 16K [0x22990000, 0x22a90000, 0x22e70000)
  eden space 896K,   0% used [0x22990000, 0x22990810, 0x22a70000)
  from space 64K,  22% used [0x22a70000, 0x22a738b0, 0x22a80000)
  to   space 64K,   0% used [0x22a80000, 0x22a80000, 0x22a90000)
 tenured generation   total 4096K, used 328K [0x22e70000, 0x23270000, 0x26990000)
   the space 4096K,   8% used [0x22e70000, 0x22ec2328, 0x22ec2400, 0x23270000)
 compacting perm gen  total 12288K, used 152K [0x26990000, 0x27590000, 0x2a990000)
   the space 12288K,   1% used [0x26990000, 0x269b6390, 0x269b6400, 0x27590000)
    ro space 8192K,  63% used [0x2a990000, 0x2aea3ae8, 0x2aea3c00, 0x2b190000)
    rw space 12288K,  53% used [0x2b190000, 0x2b7f83f8, 0x2b7f8400, 0x2bd90000)
 
This shows you the sizes of the various parts of the heap, how large they were and the amount used at the time the application quit.  It's a good snapshot of the application's heap requirements at the end of the run and can help you tune.   As an example, if the new generation used is close to the total size of the new generation then you should increase the nursery size using "-Xmn" flag.  Again having to garbage collect is expensive, and causes your application to stop executing while the collection happens.  The fewer you have to do the faster your application runs.  And a full GC is slower than a regular GC.  If your application is causing many full GCs to happen and your tenured generation is nearly full then modify the nursery (-Xmn) such that the nursery is a smaller portion of the total heap size.
 
Stay tuned for part 3 as we discuss how to combine GC flags and heap flags to tune a real application for maximum performance.

Consider a simple Rectangle class's constructor.

class Rectangle{

private int x,y,w,h; // x, y, width and height

Rectangle(int _x, int _y, int _w, int _h){

// Intialize  x, y, w and h

}

}

As API developers, we are always attempting to balance functionality and convenience. Even this fairly straightforward class can become confusing when we try to provide convenient alternative constructors. 

If, for example, our Rectangle's w and h were usually 100 we may be tempted to create a constructor which defers to the original constructor with default values.

Rectangle(int _x, int _y){

this(_x, _y, 100, 100);

}

One might also allow a default for when h and w are 100 and x and y are 0

Rectangle(){

this(0, 0, 100, 100);

}

Things get tricky when we then try to create a constructor where we specify the w and h and take the default x and y.

We might be tempted to try to add this constructor

Rectangle(int _w, int _h){

this(0, 0, _w, _h);

}

Sadly, this constructor is now ambiguous and will result in a compile failure. If you look at Rectangle(int _x, int _y),  it is the same. The compiler does not care what the variable names are, there can only be one constructor taking (int,int).

It would be great if Java had a syntax for disambiguating the arguments to a method or constructor .

Rectangle r = new Rectangle(width:100, x:20);

We could specify the arguments in any order and the compiler would create a synthetic constructor which matched the arguments; alas Java cannot do this although we will see later how we can get close to this.

Of course, if we did not want our Rectangle to be immutable, we can abandon having multiple constructors and just use mutators.

Rectangle r = new Rectangle(); // defaults x,y = 0 and width,height=100

r.setWidth(500);

r.setHeight(500);

This is probably the best approach for most classes; it is a little verbose but it is easy to understand.

However, for immutable classes we need another approach.  

Thankfully, we can use a builder pattern.

If we define an inner static class within Rectangle called Builder which we can mutate into an appropriate state (using regular setters), we can then pass this builder into Rectangle's constructor and let the constructor pull its own state from the builder.

Sounds more complicated than it is. So lets see what this looks like:

class Rectangle{

private int x,y,h,w;

public static class Builder{

protected int x,y,h,w;

void setW(int _w){w = _w; }

void setX(int _x){x = _x;}

void setY(int _y){y = _y;}

void setH(int _h){h = _h;}

}

public Rectangle(Builder _builder){

x=_builder.x;

y=_builder.x;

w=_builder.w;

h=_builder.h;

}

}

So now we can create an instance of Rectangle.Builder and mutate it.

Then we can create a Rectangle by passing the Rectangle.Builder to the constructor.

Rectangle.Builder builder = new Rectangle.Builder();

builder.setW(500);

builder.setH(1000);

Rectangle rectangle = new Rectangle(builder);

We can make code less verbose by using what I will call 'chainable mutators' to the builder.  Unlike traditional mutators, we avoid using the traditional setX() style for field x;instead we just name the mutator the same as the field (so we use x() instead ofsetX()). We also return 'this' from our mutator so that subsequent mutator calls can be chained together.

Our builder mutators now look like this:

Builder w(int _w){

w = _w;

return(this);

}

And so now we can use:

Rectangle.Builder builder = new Rectangle.Builder();

builder.w(200).h(200).x(5).y(5);

Rectangle rectangle = new Rectangle(builder);

We can construct and chain in one line:

Rectangle.Builder builder = new Rectangle.Builder().w(200).h(200).x(5).y(5);

Rectangle rectangle = new Rectangle(builder);

Or we can avoid declaring the temporary builder object altogether.

Rectangle r = new Rectangle(new Rectangle.Builder().w(200).h(200).x(5).y(5));

Now we have the safety of immutable Rectangles with a mechanism for getting immutable objects into a reasonable state.

At this point we can make two more enhancements.

1.       Add a static build() method to Rectangle to construct the Rectangle.Builder.

2.       Add a commit() method to the Rectangle.Builder to construct the Rectangle.

Our code now looks like this:

class Rectangle{

private int x,y,h,w;

public static class Builder{

protected int x,y,h,w;

Builder w(int _w){w = _w; return(this);}

Builder x(int _x){x = _x; return(this);}

Builder y(int _y){y = _y; return(this);}

Builder h(int _h){h = _h; return(this);}

Rectangle commit(){return new Rectangle(this);}

}

private Rectangle(Builder _builder){

x=_builder.x;

y=_builder.x;

w=_builder.w;

h=_builder.h;

}

Builder build(){

return(new Builder());

}

}

And we can create a Rectangle using:

Rectangle r = Rectangle.build().w(200).h(200).x(5).y(5).commit();

This pattern is certainly not new. It borrows from the traditional builder pattern and from what Martin Fowler refers to as a 'fluent interface': (http://martinfowler.com/bliki/FluentInterface.html).

We have been using this pattern in internal projects and would be interested to hear how folks feel about combining the builder pattern with chainable mutators for constructing immutable objects.

I'm going to be using the Sun HotSpot JVM flags as my examples but both Oracle's JRockit and IBM's J9 have similar flags. See the appropriate documentation on Oracle's or IBM's site, respectively.

Traditionally most applications are throughput bound and are not sensitive to GC pause times. Throughput bound applications are better suited to a fast collection where the JVM can pause Java execution for GC. There is another class of applications that require a certain guarantee of how long the GC pauses will take. These applications are popular in the financial sector and other related fields. These applications require that the JVM ensures that individual transactions finish within a certain time period, usually less than 10ms.

Let's start with the most common applications first and target throughput applications. The first flag to enable is "-XX:+UseParallelOldGC" which enables a parallel version of both the young generation collector and the old generation collector. By default the number of threads is some variant of the number of processors that changes depending on the version of Java. We should change that to some reasonable default depending on the number of cores that you have available on your system and more importantly the number of cores you want to dedicate to this application. In this example I'm going to assume the system has two processors and eight cores (2p/8c). Since the application I want to run is exclusively dedicated to the system I'm also going to set aside all eight cores to garbage collection. Now this isn't as bad as you realize since the ParallelGC is a "Stop the world" collector and your Java application won't make forward progress until the collection has completed. To modify the number of threads use the flag: "-XX:ParallelGCThreads=#" where # is the number of threads in our case 8.

Once you've enabled those flags test the application out and see how much performance you've gained. Ideally your application should now run faster and have shorter garbage collection pause times. What about other applications that are latency driven rather than performance driven? For those applications we need to enable the low pause or concurrent collector. To enable the concurrent collector we use the flag "-XX:+UseConcMarkSweepGC" which enables the concurrent collector. But since we care about latency and don't want GC time to dominate over application CPU use time we need to enable the incremental mode for CMS by using "-XX:+CMSIncrementalMode". These two flags only get maximum impact when the JVM knows what the collector is doing and is able to profile and change parameters. To enable that feature use "-XX:+CMSIncrementalPacing".

Now rerun your application and see if the response time for your application has increased. In most cases while response time may have increased, your throughput may have dropped, but whether that tradeoff is acceptable is a decision only you can make. Stay tuned next time as we explore how to use GC logs to tune heap sizes and control GC performance.

-------------------------

Azeem Jiva, MTS Software Engineer

In our next entry, we’ll look at how Windows-based systems handle huge pages and NUMA. Meanwhile, I’d be interested in cases where people have actually used huge pages and affinity on Linux.

Now imagine you want to parameterize your new library routine, perhaps tweaking a value for some performance testing as part of a runtime script.  For most library routines a system property can be used.  Your library source would then have something like

   final static int myParam = Integer.getInteger("myParam", 6);

where 6 is the default if the property doesn't exist and you would use -DmyParam=nnn on the JVM command line to specify other values.

However, some classes (java.util.HashMap, for example) are loaded early enough in the boot process that you can't use Properties in that class, because the Properties class itself depends on the class like HashMap that is being loaded.

One way to work around this without rebuilding your HashMap class on every run is to have your parameterized HashMap get the myParam value from a separate very simple class.  You would then build a different version of the simple class for each different parameter value you wanted to use.  Your library source would then have something like

   final static int myParam = myPackage.MySimpleClass.param;

and MySimpleClass.java would contain

   Package myPackage;

   public class MySimpleClass {public static int param = 2;}

At javac compile time, you would compile HashMap against some random version of MySimpleClass  but at run time you could add to the bootclasspath a .jar file containing the actual MySimpleClass parameter you want to use.

Note that in the above examples, we declared myParam itself to be final.  In some cases, this helps the JIT compiler generate better code in our new class.  Note also that we were careful NOT to make the param in MySimpleClass final.  If this had been final, the javac compiler would have propogated the final constant over to our class, and then our override with a different class at run time would have no effect.

I'm interested in techniques others may have used to solve this problem.

AMD is a strong supporter of (and contributor to) benchmarking standards via organizations like SPEC.  The goal is to come up with workloads that are representative of applications, hopefully your applications, so that you can use the results as data points in software and hardware purchasing decisions.  Having said that, we also realize that benchmark results taken out of context won’t help you make those decisions. 

Pat Moorhead, our V.P. of Advanced Marketing, said it well in his blog.  Benchmarks like SPECjbb2005 can be configured to run in a number of different ways.  Some configurations have the isolated goal of yielding the best possible performance, while others look to simulate the realities of the data center where power consumption, performance, price, and stability are all important.  You’ve got to look at the context that makes the most sense for your situation, to help you interpret the results.

Essentially, benchmark results tell a story.  You have to make sure that they fit your story, or there be nightmares in your future.

Ben