bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search

JRockit for Windows and Linux User Guide

 Previous Next Contents View as PDF  

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:

 


Native Threads

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.

 


Thin Threads

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.

 


Choosing a Thread System

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.

Pros and Cons

Table 5-1 lists the pros and cons of each thread system.

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.


Threading System Selection Matrix

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.

 


Implementing a Thread System

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.

 


Configuring the Thread System

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.

Warning: -X options are non-standard and are subject to change at any time.

Setting the Type of Thread Allocation

-Xallocationtype:<global|local>

-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.

Setting the Thread Stack Size

-Xss<size>[k|K]

-Xss<size>[k|K] sets the thread stack size in kilobytes.

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.

 

Back to Top Previous Next