Configuring the JRockit Thread System

Thread systems allow you to configure JRockit to take optimal advantage of the resources upon which you are running it. JRockit supports two types of thread systems:

This section describes how to select and configure these thread systems. It includes information on the following subjects:

This is JRockit's default thread system. It maps Java threads directly to the operating system threads, taking advantage of the operating system's thread scheduling and load balancing policies.

Called the BEA JRockit High Performance Threading System, or thin threads, these Java threads are more specific and demand fewer resources than operating system threads. Thin threads are independent of platform-specific (native) threads. They are implemented in JRockit and are not part of the operating system; that is, several threads are simulated by one (or more) native threads that represent the running program. Context switches and scheduling is done internally within JRockit, and is therefore much lighter-weight than context switching done within native threads by the OS.

With thin threads, several Java threads are run in the same operating system thread. This means JRockit uses less memory to perform optimized thread scheduling, thread switching, and thread synchronization. This makes it possible to run a significantly higher number of threads at a higher speed than with any other Java VM.

To fully utilize system resources on a multi-processor system, JRockit is not restricted to running all Java threads in the same operating system thread. A variety of operating system threads can be used which splits the Java threads among them. A Java thread is not bound to a specific operating system thread; it can move between them to allow for optimal load balancing.

This section includes some tools that will help you determine which threading model is right for your JRockit implementation. It contains a list of the pros and cons of each method and a decision matrix that will help you identify the optimal threading model.

Table 5-1 Thread System Pros and Cons

Thread System	Pros	Cons
Native Threads	Takes advantage of the operating system's thread scheduling and load balancing policies. Are standard, giving you an application with native code, which relies upon the fact that each Java thread is mapped on to a operating system thread of its own, this is the only model that works (both DB2 and Oracle level 2 JDBC database drivers have been known to rely upon this). On a multiprocessor system when the application has few active threads, the operating system scheduling system is better at utilizing the CPUs efficiently.	Context switching is more costly as it has to be done in the operating system instead of only in the JVM. Every Java thread consumes more resources, because it requires an operating system thread of its own.
Thin Threads	Since several Java threads are run in the same operating system thread, JRockit can perform optimized thread scheduling, thread switching, and thread synchronization with less memory. A variety of operating system threads can be used, splitting the Java threads among them. A Java thread is not bound to a specific operating system thread, so it can move between them to allow for optimal load balancing.

Thread System

Pros

Cons

Native Threads

Takes advantage of the operating system's thread scheduling and load balancing policies.

Are standard, giving you an application with native code, which relies upon the fact that each Java thread is mapped on to a operating system thread of its own, this is the only model that works (both DB2 and Oracle level 2 JDBC database drivers have been known to rely upon this).

On a multiprocessor system when the application has few active threads, the operating system scheduling system is better at utilizing the CPUs efficiently.

Context switching is more costly as it has to be done in the operating system instead of only in the JVM.

Every Java thread consumes more resources, because it requires an operating system thread of its own.

Thin Threads

Since several Java threads are run in the same operating system thread, JRockit can perform optimized thread scheduling, thread switching, and thread synchronization with less memory.

A variety of operating system threads can be used, splitting the Java threads among them. A Java thread is not bound to a specific operating system thread, so it can move between them to allow for optimal load balancing.

Use the If... column in Table 5-2 to locate a condition that matches your JRockit implementation and select the thread system indicated in the Select this Method... column.

Table 5-2 Threading System Selection Matrix

If...	Select this Method...
You have in excess of a couple hundred threads	Thin Threads
You are running Linux on a single-CPU system	Thin Thread. This is because Linux threads are very expensive to use.

To implement a thread system, include one of the options listed in Table 5-3 when you start JRockit:

Table 5-3 Options Used to Implement Threading

To Use...	Include this Option...
Native Threads	-Xnativethreads This option is the default, therefore you only need to specify it when you want to change the method from thin threads.
Thin Threads	-Xthinthreads This option is not available on IA64.

To Use...

Include this Option...

Native Threads

-Xnativethreads

This option is the default, therefore you only need to specify it when you want to change the method from thin threads.

Thin Threads

-Xthinthreads

This option is not available on IA64.

To provide the optimal out-of-the-box experience with JRockit comes with default values that adapt automatically to the specific platform on which you are running JRockit (see System Defaults" on page 6-9). You can modify these values to configure your thread system by specifying at the command line any of the options listed in this section.

-Xallocationtype sets the type of thread allocation. The allocation type local is recommended for the vast majority of applications. However, if the maximum heap size is very small (less then 128 MB) or if the number of threads used by the application is very high (several hundred) the allocation type global might work better, particularly on single CPU systems. The reason for this is that every thread-local area consumes a fixed amount of memory (approximately 2 kilobytes). If the number of threads is very high or the heap size very small when using thread-local allocation the potential waste of space could cause excess fragmentation of the heap. This leads to more frequent garbage collections and may cause the application to run out of memory prematurely.

In addition to setting the thread stack size, if the number of threads is high, you should use -Xallocationtype:global, as suggested in Setting the Type of Thread Allocation to reduce heap fragmentation.