What set the value of JVM parameter MaxNewSize? Ergonomics?

Question

My server info:

• CPU:Intel Xeon E5-2630
• Memory:65970676K
• OS:Centos 6.4
• kernel:3.8.0
• jdk: HotSpot JDK 1.6.0.27

I use jmap -heap pid to print heap info:

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize      = 21474836480 (20480.0MB)
NewSize          = 21757952 (20.75MB)
MaxNewSize       = 174456832 
OldSize          = 65404928 (62.375MB)
NewRatio         = 7
 SurvivorRatio    = 8
PermSize         = 268435456 (256.0MB)
MaxPermSize      = 268435456 (256.0MB)

And following are the JVM args I defined to run my application:

 -verbose:gc  -XX:+UseMembar -XX:+PrintGCDetails - 
 XX:+PrintGCTimeStamps  -XX:+DisableExplicitGC - 
 XX:+CMSClassUnloadingEnabled
-XX:-OmitStackTraceInFastThrow  -Xloggc:/export/logs/gc.log 
-XX:PermSize=256m -XX:MaxPermSize=256m -Xms6G  -Xmx12G

I don't set MaxNewSize, I tried to use java -XX:+PrintFlagsFinal to print all of the JVM args and found MaxNewSize is a very very big number: 18446744073709486080. I think Ergonomics may have set MaxNewSize to 174456832 for me. However, I have another server, which has the same hardware and software, where MaxNewSize is 392560640 while other heap parameters are the same.

What's the basis for Ergonomics setting the value of MaxNewSize? Can I see this in the source code of Ergonomics?

I think I found where the value of MaxNewSize is set:Arguments.cpp (hotspot\src\share\vm\runtime)

if (CMSUseOldDefaults) {  // old defaults: "old" as of 6.0
  if FLAG_IS_DEFAULT(CMSYoungGenPerWorker) {
    FLAG_SET_ERGO(intx, CMSYoungGenPerWorker, 4*M);
  }
  young_gen_per_worker = 4*M;
  new_ratio = (intx)15;
  min_new_default = 4*M;
  tenuring_default = (intx)0;
} else { 
  // new defaults: "new" as of 6.0
  young_gen_per_worker = CMSYoungGenPerWorker;
  new_ratio = (intx)7;
  min_new_default = 16*M;
  tenuring_default = (intx)4;
}

// Preferred young gen size for "short" pauses
const uintx parallel_gc_threads =
(ParallelGCThreads == 0 ? 1 : ParallelGCThreads);

 const size_t preferred_max_new_size_unaligned =
    ScaleForWordSize(young_gen_per_worker * parallel_gc_threads);
  const size_t preferred_max_new_size =
align_size_up(preferred_max_new_size_unaligned, os::vm_page_size());

Answer 1

In JDK 5, a new performance feature for self tuning of the JVM known as JVM Ergonomics was added. This is also in JDK 6. The idea is that when the java process gets started, it can examine the underlying system resources and determine some of the tuning parameters automatically in the case certain options are not set. In other words, it is trying to provide a good performance from the JVM with a minimum of command line tuning.

Generation: Beginning with the J2SE Platform version 1.2, the virtual machine incorporated a number of different garbage collection algorithms that are combined using generational collection. While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to avoid extra work.

Sizing Generation A number of parameters affect generation size. At initialization of the virtual machine, the entire space for the heap is reserved. The size of the space reserved can be specified with the -Xmx option. If the value of the -Xms parameter is smaller than the value of the -Xmx parameter, not all of the space that is reserved is immediately committed to the virtual machine. The uncommitted space is labeled "virtual". The different parts of the heap ( permanent generation, tenured generation, and young generation) can grow to the limit of the virtual space as needed.

Some of the parameters are ratios of one part of the heap to another. For example the parameter NewRatio denotes the relative size of the tenured generation to the young generation.

Young Generation The second most influential knob is the proportion of the heap dedicated to the young generation. The bigger the young generation, the less often minor collections occur. However, for a bounded heap size a larger young generation implies a smaller tenured generation, which will increase the frequency of major collections. The optimal choice depends on the lifetime distribution of the objects allocated by the application.

By default, the young generation size is controlled by NewRatio. For example, setting -XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one fourth of the total heap size.

The parameters NewSize and MaxNewSize bound the young generation size from below and above. Setting these equal to one another fixes the young generation, just as setting -Xms and -Xmx equal fixes the total heap size. This is useful for tuning the young generation at a finer granularity than the integral multiples allowed by NewRatio.

If you need more info on this topic here are couple of useful links:

• Java HotSpot VM Options
• Tuning Garbage Collection with the 5.0 JVM