Useful JVM tunings

Categories of Java HotSpot VM Options

Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:

* Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
* Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice.

Some Useful -XX Options

Default values are listed for Java SE 6 for Solaris Sparc with -server. Some options may vary per architecture/OS/JVM version. Platforms with a differing default value are listed in the description.

* Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>.
* Numeric options are set with -XX:<option>=<number>. Numbers can include ‘m’ or ‘M’ for megabytes, ‘k’ or ‘K’ for kilobytes, and ‘g’ or ‘G’ for gigabytes (for example, 32k is the same as 32768).
* String options are set with -XX:<option>=<string>, are usually used to specify a file, a path, or a list of commands

Flags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, The manageable flags can also be set through jinfo -flag.

The options below are loosely grouped into three categories.

* Behavioral options change the basic behavior of the VM.
* Performance tuning options are knobs which can be used to tune VM performance.
* Debugging options generally enable tracing, printing, or output of VM information.

1. Behavioral Options

Option and Default Value

Description
-XX:-AllowUserSignalHandlers    Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.)

-XX:AltStackSize=16384    Alternate signal stack size (in Kbytes). (Relevant to Solaris only, removed from 5.0.)

-XX:-DisableExplicitGC    Disable calls to System.gc(), JVM still performs garbage collection when necessary.

-XX:+FailOverToOldVerifier    Fail over to old verifier when the new type checker fails. (Introduced in 6.)

-XX:+HandlePromotionFailure    The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.]

-XX:+MaxFDLimit    Bump the number of file descriptors to max. (Relevant  to Solaris only.)

-XX:PreBlockSpin=10    Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.)

-XX:-RelaxAccessControlCheck    Relax the access control checks in the verifier. (Introduced in 6.)

-XX:+ScavengeBeforeFullGC    Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

-XX:+UseAltSigs    Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.)

-XX:+UseBoundThreads    Bind user level threads to kernel threads. (Relevant to Solaris only.)

-XX:-UseConcMarkSweepGC    Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1)

-XX:+UseGCOverheadLimit    Use a policy that limits the proportion of the VM’s time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)

-XX:+UseLWPSynchronization    Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.)

-XX:-UseParallelGC    Use parallel garbage collection for scavenges. (Introduced in 1.4.1)

-XX:-UseParallelOldGC    Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)

-XX:-UseSerialGC    Use serial garbage collection. (Introduced in 5.0.)

-XX:-UseSpinning    Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true]

-XX:+UseTLAB    Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false]

-XX:+UseSplitVerifier    Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false]

-XX:+UseThreadPriorities    Use native thread priorities.

-XX:+UseVMInterruptibleIO    Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.)

2. Performance Options

Option and Default Value
Description
-XX:+AggressiveOpts    Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.)

-XX:CompileThreshold=10000    Number of method invocations/branches before compiling [-client: 1,500]

-XX:LargePageSizeInBytes=4m    Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.]

-XX:MaxHeapFreeRatio=70    Maximum percentage of heap free after GC to avoid shrinking.

-XX:MaxNewSize=size    Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]

-XX:MaxPermSize=64m    Size of the Permanent Generation.  [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]

-XX:MinHeapFreeRatio=40    Minimum percentage of heap free after GC to avoid expansion.

-XX:NewRatio=2    Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86 -client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12]

-XX:NewSize=2.125m    Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]

-XX:ReservedCodeCacheSize=32m    Reserved code cache size (in bytes) – maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]

-XX:SurvivorRatio=8    Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]

-XX:TargetSurvivorRatio=50    Desired percentage of survivor space used after scavenge.

-XX:ThreadStackSize=512    Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

-XX:+UseBiasedLocking    Enable biased locking. For more details, see this tuning example. (Introduced in 5.0 update 6.) [5.0: false]

-XX:+UseFastAccessorMethods    Use optimized versions of Get<Primitive>Field.

-XX:-UseISM    Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory.

-XX:+UseLargePages    Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages.

-XX:+UseMPSS    Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]

-XX:+StringCache    Enables caching of commonly allocated strings.

-XX:AllocatePrefetchLines=1    Number of cache lines to load after the last object allocation using prefetch instructions generated in JIT compiled code. Default values are 1 if the last allocated object was an instance and 3 if it was an array.

-XX:AllocatePrefetchStyle=1    Generated code style for prefetch instructions.
0 – no prefetch instructions are generate*d*,
1 – execute prefetch instructions after each allocation,
2 – use TLAB allocation watermark pointer to gate when prefetch instructions are executed.

3. Debugging Options

Option and Default Value
Description
-XX:-CITime    Prints time spent in JIT Compiler. (Introduced in 1.4.0.)

-XX:ErrorFile=./hs_err_pid<pid>.log    If an error occurs, save the error data to this file. (Introduced in 6.)

-XX:-ExtendedDTraceProbes    Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.)

-XX:HeapDumpPath=./java_pid<pid>.hprof    Path to directory or filename for heap dump. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)

-XX:-HeapDumpOnOutOfMemoryError    Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)

-XX:OnError=”<cmd args>;<cmd args>”    Run user-defined commands on fatal error. (Introduced in 1.4.2 update 9.)

-XX:OnOutOfMemoryError=”<cmd args>;
<cmd args>”     Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6)

-XX:-PrintClassHistogram    Print a histogram of class instances on Ctrl-Break. Manageable. (Introduced in 1.4.2.) The jmap -histo command provides equivalent functionality.

-XX:-PrintConcurrentLocks    Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -l command provides equivalent functionality.

-XX:-PrintCommandLineFlags    Print flags that appeared on the command line. (Introduced in 5.0.)

-XX:-PrintCompilation    Print message when a method is compiled.

-XX:-PrintGC    Print messages at garbage collection. Manageable.

-XX:-PrintGCDetails    Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)

-XX:-PrintGCTimeStamps    Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)

-XX:-PrintTenuringDistribution    Print tenuring age information.

-XX:-TraceClassLoading    Trace loading of classes.

-XX:-TraceClassLoadingPreorder    Trace all classes loaded in order referenced (not loaded). (Introduced in 1.4.2.)

-XX:-TraceClassResolution    Trace constant pool resolutions. (Introduced in 1.4.2.)

-XX:-TraceClassUnloading    Trace unloading of classes.

-XX:-TraceLoaderConstraints    Trace recording of loader constraints. (Introduced in 6.)

-XX:+PerfSaveDataToFile    Saves jvmstat binary data on exit.

source http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html


Thanks
R Vashi

Advertisements

java.lang.OutOfMemoryError: PermGen space

Hi All,

Few days back I was reading one of the article of my all time favorite guru(Jaysen sharma), So I would like to share that in this article.

In case of OutOfMemoryError in PermGen Sapace …increasing only the Heap Size will not solve anything…

Formula:

(OS Level)Process Size = Java Heap Native Space (2-3% OS related Memory)

PermSize : It’s a Native Memory Area Outside of the Heap, Where ClassLoading kind of things happens…. In an operating System like Windows Default Process Size is 2GB (2048MB) default (It doesn’t matter How much RAM do u have 2GB or 4GB or more)…until we don’t change it by setting OS level parameter to increase the process size..Usually in OS like Solaris/Linux we get 4GB process size as well.

Now Lets take the default Process Size=2GB (Windows), Now if you have set the -Xmx512M, we can assume that rest of the memory 1536 Mb is available for Native codes.

(ProcessSize (-) HeapSize) = Native (+) (2-3% OS related Memory)

2048 MB (-) 512 MB = 1536 MB

THUMB RULES:

MaxPermSize = (Xmx/3) —- Very Special Cases (One Third of maximum Heap Size)

MaxPermSize = (Xmx/4) —- Recommended (One Fourth Of maximum Heap Size)

So finally you need to increase the PermGen Size… like -Xmx1024m -Xms1024m -XX:MaxPermSize256m

But again these are not the Final values … It depends on ther Environments

Thanks

R Vashi.

Deleting record in J2ME RMS

Hi All,

The below examples will show how to delete a record in RMS database in Midlet application. There is an API in RecordStore which deletes a record by taking recordId as an input.

public boolean deleteRecord(int recordId){

RecordStore rec=null;
try{
rec=RecordStore.openRecordStore(“notes”, true );
rec.deleteRecord(recordId); // delete a record in Record Store.
return true;

}catch(Excecption ex){
return false;
}finally{
rec.closeRecordStore();

}

}

Thanks

R Vashi.

J2ME Search example in Middlet Record Store

Hi

The below example is used to show the way we can search the data in Record Store of Middlet, This example is based on login authentication where the data has stored in special format [username]#[password] e.g testuser#password.

import javax.microedition.rms.*;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.io.*;

public class ExampleSearch
{

private RecordStore recordstore = null;
private RecordEnumeration recordEnum= null;
private Filter filter = null;

// get the record store
public void getRecStore(){
recordstore= RecordStore.openRecordStore(“myRec”,true);
}
//
public boolean login(String userName,String password){
getRecStore();
filter = new Filter(userName+”#”+password); // create a filter on the search text
recordEnum= recordstore.enumerateRecords(filter, null, false);
if (recordEnum.numRecords() > 0)
{
return true;
}else{
return false;
}
}

}

/*
*    This class is used as a filter for this example which is exetnding the RecordFilter
*
*
*/
class Filter implements RecordFilter{
private String search = null;
private ByteArrayInputStream inputstream = null;
private DataInputStream datainputstream = null;
public Filter(String search)
{
this.search = search.toLowerCase();
}
public boolean matches(byte[] suspect)
{
String string = new String(suspect).toLowerCase();
if (string!= null && string.indexOf(search) != -1)
return true;
else
return false;
}
public void filterClose()
{
try
{
if (inputstream != null)
{
inputstream.close();
}
if (datainputstream != null)
{
datainputstream.close();
}
}
catch ( Exception error)
{
}
}
}

Thanks
R Vashi

J2ME setup for Nokia Devices

Hi

This section describes the J2ME environment setup for Nokia devices. Nokia provides different SDK’s to develop its various devices, That include Series 60,40 type of SDK’s.

To get details of the which Nokia device uses which SDK, you can refer the below link.
http://www.forum.nokia.com/devices/matrix_all_1.html

After getting the device details, You can start developing application for your Nokia device. See below the steps for configuring the J2ME development environment.

J2ME Setup for Nokia

Step 1:

Install Sun Java Wireless Toolkit

The Sun Java Wireless Toolkit is a toolbox for developing wireless applications that are based on JavaME’s Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP). The toolkit includes an emulation environments that you can emulate different mobile devices.

Download Installer for Windows:
sun_java_wireless_toolkit-2.5.2_01-win.exe

A list of all available versions:

http://java.sun.com/products/sjwtoolkit/

Step 2:

Install Eclipse Galileo Pulsor edition specially designed for J2ME environment. Pulsar is a tools integration platform for the mobile developer. It make it easy to get the tools and handset SDKs you need for developing mobile applications.
http://www.eclipse.org/pulsar/

Step 3:
You can download S40, S60 Series SDK from the below URL.

http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/


Step 4:

After installing the Nokia series SDK, Configured your device in Eclipse IDE. So that SDK generates the packages compatible with Nokia Device.

  1. Open Eclipse.
  2. Select Window > Preferences.
  3. Select Java ME > Device Management.
  4. Click Import.
  5. Click Browse and select the folder where you installed the SDK. Eclipse searches the selected folder for available device definitions. [by default 60 series SDK gets installed in C:\60]
  6. Select the device definitions and click Finish.

Step 5:
Select the default device definition for new Java ME projects by checking it in the Default column. If you want to develop for Symbian devices, check S60Emulator. To complete the configuration, click OK.

Your development environment is now set and you can create the MIDlet in Eclipse.

Complete Source at Nokia’s Website [http://library.forum.nokia.com/]

Thanks
R Vashi