IBM BS029ML Self Help Guide - Page 159

%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