Table of Contents
Advertisement
%CPU. More GC threads (-XgcthreadsN) will provide more mark stacks (and queues), which
means less likelihood of a mark stack overflow. A Java heapdump analysis may also help.
Just-In-Time Compiler (JIT or JITC)
By default, the IBM JVM ships with the JIT (Just-In-Time) compiler enabled. JIT effectively
offers a performance improvement by replacing some of the commonly used Java methods
and objects with highly optimized C and Assembler routines. This, by necessity, requires an
amount of native memory to accommodate the compilation and resulting code set.
It is also worth noting that with JIT enabled, contending methods are not immediately
compiled. Instead, such methods are only JIT compiled after they have been invoked after a
certain number of times or threshold. This may well present itself as a delayed growth in
native memory and could be misinterpreted as a native memory leak (also a performance
issue).
It is possible to force JIT to compile methods up front without delay. However, this approach is
not normally recommended and thus is not documented here.
Native memory associated with the IBM JVM
It is important to remember that when dealing with a JVM that there is an amount of native
memory associated with the process. The types of objects allocated in the native heap or
permitted "data area" for the IBM JVM are as follows:
Just-In-Time (JIT) Compiled code
Java Native Interface (JNI™) code
Native Thread Stacks
Inflators / Deflators
GZipOutputStreams
Class Loaded data
IBM JVM CPU utilization
If a system is observed to consume a very high % of CPU for a process associated with the
WebSphere JVM, then this could be indicative of spending too much time performing Java
garbage collection (GC). In such cases, the recommended action is to use either Tivoli
Performance Viewer or a verbose garbage collection trace to identify the characteristics of the
Java heap.
If you deduce that it is indeed the Java garbage collection (GC) cycle that is stealing CPU, it
does not necessarily indicate a JVM performance or defect issue. More commonly, it may
indicate an object management issue in the application or WebSphere. Remember that if a
reference to an object is not released, then GC will be unable to free that memory back to the
heap; vectors and arrays are particularly prone to this problem if coded incorrectly (session
beans and self-grown caches).
5.2.3 Tuning advice for the SUN Microsystems Java Virtual Machine (JVM)
There are major differences between the IBM and SUN Microsystems JVM implementations.
It is therefore important to recognize that the SUN JVM includes a generational heap, which
splits objects between a Young (Eden) generation (objects are created here) and an Older
generation (objects are promoted to the older generation). Each generation is garbage
collected (GC) independently and uses a different collection strategy. There also exists a
Permanent generation that typically holds class loaded data.
Chapter 5. WebSphere Portal runtime and services
145
Advertisement
Table of Contents
Troubleshooting
