HotSpot JVM Default Parameters
These tuning options are configured by default in Sterling B2B Integrator on HotSpot JVMs in Windows, Solaris, and HP-UX.
The options, -d32 and –d64 are added to the Java™ launcher to specify if the program should be run in a 32-bit or a 64-bit environment. On Solaris, they correspond to the ILP32 and LP64 data models. Since Solaris contains both 32-bit and 64-bit J2SE implementation within the same Java installation, you can specify either version. If neither –d32 nor –d64 is specified, it will run in 32-bit environment by default. Java commands such as javac, javadoc, and so on may rarely need to be run in a 64-bit environment. However, it may be required to pass the -d32 or –d64 options to these commands and then to the Java launcher using –J prefix option, for example, -J-d64. For other platforms such as Windows and Linux®, 32-bit and 64-bit installation packages are separate. If you have installed both 32-bit 64-bit packages on a system, you can select either one of them by adding the appropriate bin directory to the path.
Sterling B2B Integrator 5.2 supports 64-bit architecture on most operating systems. The –d64 option is the default value on Windows Server 2008, Solaris, and HP-UX for both noapp JVM and container JVM. However, on Windows Server 2003, the –d32 option is default as it uses a 32-bit JDK.
Parameter / Description |
Default Value |
|---|---|
-serverHotSpot-based JVMs generally use low optimization levels, which takes less time to start up, but leads to low runtime performance. Normally, a simple JIT compiler is used. To increase the runtime performance for applications such as Sterling B2B Integrator, an optimizing compiler is recommended. Using this method may, however, lead a JVM to take longer time to warm up. |
For both noapp and container JVMs:
|
-XmxIf this parameter is
tuned correctly, it can:
If you see a large number of garbage collections, try increasing the value. You can set a maximum heap limit of 4 GB for a 32-bit JVM. However, due to various constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, it is recommended to set a lower value. In 32-bit Windows systems, the maximum heap size can be set in the range from 1.4 GB to 1.6 GB. Similarly, on 32-bit Solaris kernels, the address space is limited to 2 GB. The maximum heap size can be higher if your 64-bit operating system is running 32-bit JVM, reaching until 4 GB on Solaris systems. Java SE 6 does not support Windows /3GB boot.ini feature. If you require a large heap setting, you should use a 64-bit JVM on an operating system supporting 64-bit applications. |
Refer to Edit Performance Configuration Settings for
the default values for the:
|
-XX:+DisableExplicitGCDisables the explicit garbage collection calls that are caused by invoking System.gc() inside the application. It is recommended that the developers avoid the System.gc() calls to cause programmer-initiated, full-compaction garbage collection cycles, because such calls can interfere with the tuning of resources and garbage collection for the entire application system. If your application pause times caused by System.gc() are more than your expected pause times, it is strongly recommended that you use this option to disable the explicit GC, so that the System.gc() calls will be ignored. |
For both 32-bit/64-bit noapp and container
JVMs:
|
-XX:NewSize= and -Xmn<Size>=–XX:NewSize controls the minimum young generation size in a heap, and the –Xmn sets the size of the young generation heap. It is recommended
to use the following formula to compute - XX:NewSize and -Xmn values
when the minimum heap size and maximum heap sizes are modified.
|
Refer to Edit Performance Configuration Settings for the default values
for the:
|
-XX:MaxPermSizeStores all the class code and class-like data. The value of the parameter should be large enough to fit all the classes that are concurrently loaded. Sometimes, it is difficult to determine the actual value of this parameter because generally, this region is smaller and expands slowly, and the utilization is commonly observed at 99-100 percent of its current capacity. If you have not configured this region correctly, the JVM might fail with the Java.lang.OutOfMemoryError: PermGen space error. |
Refer to Edit Performance Configuration Settings for the default values
for the:
|
-XssDetermines the stack size for each thread in the JVM. Every thread in a JVM gets a stack, and this value determines the number of threads you can start in a JVM. If this value is too large, you might run into an OOM. Each time a method is invoked, a stack frame is created and pushed into the thread stack. At a minimum, a stack frame contains a method's local variables and arguments. If a thread's actual stack size reaches beyond this limit, you will get a java.lang.StackOverflowError exception. |
Refer to Edit Performance Configuration Settings for
the default values for the:
|
-XX:CompileThresholdDetermines the number of method invocations and branches before compiling. Setting a low value for this parameter will trigger the compilations of hot methods sooner. |
For both 32-bit/64-bit noapp and container
JVMs:
|
-XnocatchDisables the Java catch-all signal handler. This option is used to get clean, native code stack traces. |
For both noapp and container JVMs: HP-UX = -Xnocatch |