Introduction to Oracle JRockit Real Time

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Tuning Real Time Applications for Deterministic Garbage Collection

This section contains the following guidelines for tuning your applications for the Oracle JRockit JVM deterministic garbage collector that is included with Oracle JRockit Real Time.

Note: For more information on adjusting other non-standard start-up commands available with JRockit, see the JRockit Configuration and Tuning Guide.


Basic Environment Tuning

Use these guidelines for configuring your environment to use Oracle JRockit Real Time.


Basic Application Tuning

Use these guidelines when designing your applications for Oracle JRockit Real Time.


J2EE Application Tuning

Use these guidelines when tuning your J2EE applications for Oracle JRockit Real Time.


JMS Application Tuning

Use these guidelines when using Oracle WebLogic JMS applications with JRockit Real Time.


JVM Tuning for Real-Time Applications

These tuning suggestions can further improve performance and decrease pause times when using the JRockit JVM deterministic garbage collector. For more information on the deterministic garbage collector, see the Oracle JRockit Diagnostics Guide.

Allow For a Warm-up Period

There may be a warm-up period before response times achieve desired levels. During this warm-up, JRockit JVM will optimize the critical code paths. The warm-up period is application and hardware dependent, as follows:

Adjust Min/Max Heap Sizes

Setting the minimum heap size (-Xms) smaller or the maximum heap size (-Xmx) larger affects how often garbage collection will occur and determines the approximate amount of live data an application can have. To begin with, try using the following heap sizes:

   java -Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30

For more information, see -X Command-line Options in the Oracle JRockit JVM Command-Line Reference.

Increase or Decrease Pause Targets

For more information, see -X Command-line Options in the Oracle JRockit Command-Line Reference.

Set the Page Size

Increasing the page size (-XXlargePages) can increase performance and lower pause times by limiting cache misses in the translation look-aside buffer (TLB). See -XX Command-line Options in the Oracle JRockit JVM Command-Line Reference.

Determine Optimal Load

Do not be overcautious in terms of load. The deterministic garbage collector can handle a fair amount of load without breaking its determinism guarantees. Too little load means the JVM’s optimizer and GC heuristics have too little information to work with, resulting in sub-par performance. A best practice is to run your benchmarks at various loads (with and without deterministic GC) to determine the optimal load.

Analyze GC With JRockit Verbose Output

JRockit JVM verbose output normally doesn’t incur a measurable performance impact, and is quite useful for analyzing JVM memory and GC activity. Table 2-1 defines recommended verbose options for analyzing JVM memory and GC activity.

Table 2-1 JRockit JVM Verbose Output Options
What it does...
For GC and memory analysis.
Redirects verbose output to the designated file.
Prints a formatted date before each verbose line.

Limit Amount of Finalizers and Reference Objects

Try to limit the amount of Finalizers and reference objects that are used, such as Soft-, Weak-, and Phantom- references. These types require special handling, and if they occur in large numbers then pause times can become longer than 30ms.

Adjust the Garbage Collection Trigger

Try adjusting the garbage collection trigger (-XXgctrigger) to limit the amount of heap space used. This way, you can force the garbage collection to trigger more frequent garbage collections without modifying your applications. The garbage collection trigger is somewhat deterministic, since garbage collection starts each time the trigger limit is hit. See the Oracle JRockit JVM Diagnostics Guide.

Note: If the trigger value is set to low, the heap might get full before the garbage collection is finished, causing even longer pauses for threads since they have to wait for the garbage collection to complete before getting new memory. Typically, memory is always available since a portion of the heap is free and any pauses are just the small pauses when the garbage collection stops the Java application.

Adjust the Amount of Garbage Collection Threads for Processors

With the variety of sophisticated processing hardware currently available (HyperTransport, Strands, Dual Core, etc.), the JRockit JVM may not be able to determine the appropriate number of GC threads it should start. The current recommendation is to start one thread per physical CPU; that is, one thread per chip not per core. However, having too many garbage collection threads could affect the latency of applications since more threads will be running on the system, which might saturate the CPUs, and thus affect the Java application. Conversely, setting them too low could increase the mark phase of the GC, since less parallelism is possible. For example, on a dual core Intel Woodcrest machine with four cores the recommended number of GC threads is two, which is the same as the number of processors in the machine.

To see how many garbage collection threads that the JRockit JVM uses on your machine, start the JRockit JVM with -verbose:memdbg and then check for the following lines that are printed during startup:

   [memdbg ] number of oc threads: <num>
[memdbg ] number of yc threads: <num>

If necessary, adjust the number of GC threads using the -XXgcthreads:<# threads> parameter.

For more information, see -XX Command-line Options in the Oracle JRockit JVM Command-Line Reference.


More Tuning Information

This section contains pointers to additional performance and tuning information.

JRockit JVM

See Oracle JRockit JVM Diagnostics Guide for additional diagnostic information about the Oracle JRockit JVM.

  Back to Top       Previous  Next