®

Understanding and Tuning the Java Virtual

Machine (JVM) for WebSphere

© 2006 IBM Corporation

What you should know after this talk

ƒ You should understand at a high level how the Java Virtual Machine (JVM)
operates underneath your application server and the differences between the
JVM’s on platforms

ƒ You should understand what the IBM J9 JVM is and what new features it provides
to the runtime as well as when to use those features.

ƒ You will understand how different garbage collection schemes work and how to
use them to effect your applications response times

ƒ You will have a knowledge and understanding of some critical JVM tuning
parameters that effect the runtime performance of the JVM

ƒ Lastly you will get to know which debugging tools are available for the JVM as
well as understand when and where to use them most effectively.

2
Overview

ƒ JVM Basics

ƒ Overview of IBM’s J9 JVM

ƒ Memory Management / Garbage Collection

ƒ Runtime Performance Tuning

ƒ Debugging Tools

3
JVM Basics
Highest Level Overview

ƒ Java is a Write Once Run Anywhere (WORA) 3rd generation Object Oriented
programming language that is executed on a virtual machine

ƒ The Java Virtual Machine (JVM) runs applications written in Java after the Java
code has been compiled to bytecode via the javac process.

ƒ The JVM in conjunction with other components performs optimization on your

compiled Java code to attempt to make it as fast as native code

ƒ The JVM performs automatic memory management (Garbage Collection) to

ensure that system wide memory leaks do not occur and to allow for easier
development by allowing developers not to explicitly have to perform memory
management.

ƒ There are multiple implementations of the JVM which all “should” execute any
application written for the Java specification level that JVM was developed for.

4
JVM Basics
Which JVM do I have?

ƒ The different platforms that WebSphere Application Server runs on have different
JVM implementations in some cases

ƒ The IBM J9 JVM is the runtime environment on the following Operating Systems
or Platforms
9 AIX, Windows, Linux (x86), Linux (PPC), iSeries, zSeries

ƒ The Sun JVM is the runtime environment on all platforms running the Solaris
Operating System

ƒ The HP JVM (which is a very simple Sun JVM port) is the runtime environment on
all platforms running the HP-UX Operating System

5
JVM Basics
The Overall Java Application Stack
ƒ JVM is built using OO design. Building
Block components providing higher
level function for simplified end user
development and runtime

ƒ JVM’s core runtimes are developed in C

or C++ and execute a large majority of
function in native code
9 Garbage collector, MMU, JIT, etc
9 IO subroutines, OS calls

ƒ The J2SE/J2EE APIs all exist at the

Java Code layer.
9 Makes data structures available
9 Gives users access to needed
function
9 Allow black box interactions with
system
6
 Java application code

Uses 1 of many possible

Java calls JNI
configurations

Pluggable components
that dynamically load
into the virtual machine J2SE

Virtual machine Calls to

C
JVM Profiler libraries
Class loader Native
JNI applications
Debugger
Interpreter
Realtime Profiler JCL natives
Exception handler
JIT
Garbage collector OS-specific calls

Thread model Port Library (file IO, sockets, memory allocation, etc.)

Operating system

7
JVM Basics
Class loader basics

ƒ Uses parent-delegation model to allow additional security as well as allow users

to implement their own class loaders
9 Loads classes in a hierarchical manner by delegating to the current class
loaders parent recursively

ƒ What does the class loader do?

9 Loading – Obtaining of the byte code from the java class file
9 Verification – Validates that the code inside the class file does not attempt to
perform any illegal operations in the JVM and that the class file is well formed
and not corrupt
9 Preparation – Performs allocation and initialization of storage space for static
class fields. Also creates method tables and object templates
9 Initialization – Executes the classes initialization method and initializes static
fields if your java class has them

8
JVM Basics
JIT Basics

ƒ The just-in-time compiler (JIT) is not really part of the JVM but is essential for a
high performing Java application
9 Java is Write Once Run Anywhere thus it is interpreted by nature and without
the JIT could not compete with native code applications

ƒ The JIT works by compiling byte code loaded from the class loader when it is
access by an application.
9 Due to different platforms having different JITs there is no standard method for
when a method is compiled.
9 As your code accesses methods the JIT determines how frequently specific
methods are accessed and compiles those touched often quickly to optimize
performance

9
Overview

ƒ JVM Basics

ƒ Overview of IBM’s J9 JVM

ƒ Memory Management / Garbage Collection

ƒ Runtime Performance Tuning

ƒ Debugging Tools

10
Overview of IBM’s J9 JVM
Background

ƒ IBM Toronto Laboratory has a long history (30+ years) of expertise in programming language
compilation and optimization technologies.
9 C, C++, Fortran, XML Parser, HPJ (statically compiled Java)
9 Language independent, interprocedural optimizers
9 Parallelization technology
9 Low-level compiler backends: optimizers, linkers, and code generators
9 Dynamic compilation: Java just-in-time (JIT) compilers

ƒ Close relationships with:

9 Research : productizing innovative ideas and experimental technologies.
9 Hardware : understanding how to achieve the best possible performance with the
underlying system and processor.
9 IBM Middleware : performance analysis

ƒ Deep IP portfolio
9 Java JIT group alone filed 14 U.S. patents in 2004, 6 in 2005.

11
Overview of IBM’s J9 JVM
What is the J9 JVM?

ƒ Sun IP-free, but Java 2 (1.3) compliant (J2ME) and J2SE (1.4.2, 5.0)

ƒ Highly configurable class library implementation

ƒ Multi-platform
9 PowerPC, IA32, x86-64, and 390 (Linux or z/OS)
9 More applications than the above outside of the middleware space

ƒ Flexible and sophisticated technology oriented to:

9 Performance (throughput and application startup)
9 Scalability
9 Reliability and Servicability (RAS)

12
Overview of IBM’s J9 JVM
Scalability

ƒ Garbage collector enhancements

9 Incorporates for the first time generational garbage collection

ƒ Fine-grained locking of VM data structures

ƒ Asynchronous compilation
9 Compilation of Java methods proceeds on a background thread
• Other application threads do not have to wait to execute the method
9 Improves startup time of heavily multithreaded applications on SMPs

ƒ Compile-time optimizations to remove contention

9 escape analysis, lock coarsening, …
9 architectural support to limit its effect

ƒ Superior JIT (Just in time) compiler

9 Multiple optimization methods from application profiling to more intelligent and better code
optimization algorithms

13
Overview of IBM’s J9 JVM
Key Highlights for WAS

ƒ Superior Java application execution performance

9 Just-In-Time (JIT) compiler technology
• Far improved over JDK 1.4.2 and Sun’s JIT
• Maximized performance with minimized runtime overhead
– multiple optimization levels, multiple recompilations of the
same method, many new optimizations
– dynamic observation of the execution of code via profiling
to aggressively improve hot code
– Interpreter profiling to adapt compilation to compiled
methods for block reordering, loop unrolling, etc.

14
Overview

ƒ JVM Basics

ƒ Overview of IBM’s J9 JVM

ƒ Memory Management / Garbage Collection

ƒ Runtime Performance Tuning

ƒ Debugging Tools

15
Memory Management / Garbage Collection
Overview

ƒ Garbage Collection (GC) - the main cause of memory–related performance

bottlenecks in Java.

ƒ Two things to look at in GC: frequency and duration

9 Frequency depends on the heap size and allocation rate
9 Duration depends on the heap size and Java heap footprint

ƒ GC algorithm – it is critical to understand how it works so that tuning is done

more intelligently.

ƒ How do you eliminate GC bottlenecks

9 minimize the use of objects by following good programming practices
9 Set your heap size properly, memory-tune your JVM

16
Memory Management / Garbage Collection
JVM Memory Layout

Application classes and objects

WAS Classes and Objects Java

JVM
JVM Heap
Native
Native
Heap
JVM Runtime classes, extension
Heap classes and objects

JVM
Stack JVM
Data
Segment JVM
Segment Data
Segment
JVM
Native interpreter, verifier, JIT
Code compiler, memory manager, etc
JVM OS Interface

Operating System
Operating System
Typical JVM Architecture
17
Memory Management / Garbage Collection
Total Application Memory Footprint

Application classes and objects

• Fixed Cost Application Resources, etc.
- WebSpere Runtime
- XML Parser
- ORB, JCE Security
- JMX
- Classloaders, etc Application
• User-Controlled Footprint
- Thread pool
- Connection pool
- Monitoring/Logging
- EJB cache (growable?) WAS
- Other cache (prepared statement, Footprint
security, etc )
• Application Dependent
- number of classes Native Implementation (e.g. C++)
- dynacache JVM
Data Structures, Code,
- security Footprint Runtime artifacts, OS Interface
- resources
- HTTP session size
- WLM
18
Memory Management / Garbage Collection
What factors effect memory performance the most

ƒ Memory management – how efficient does the system manage memory ?

ƒ Total available memory – is there enough memory to satisfy every request for
memory ?

ƒ Allocation Rate – how often does the application requests for memory ?

ƒ Object Size – how big are these objects ?

ƒ Object Lifetime – how long do these objects stay reserved by the application ?

19
Memory Management / Garbage Collection
Parallel VS Concurrent Collectors

ƒ Parallel Collectors – two or more threads run at the

same time to perform garbage collection
9Still uses the “stop-the-world” model but instead of
only one GC thread, there are helper threads as well.

ƒ Concurrent Collectors – collector threads are

triggered to run while applications are running
9Does not use “Stop-the-world” but threads can be
asked to perform garbage collection once in a while

20
Memory Management / Garbage Collection
What garbage collection algorithms are available on my JDK?

ƒ IBM J9 JDK Platforms

9 Memory management is configurable using four different policies with varying
characteristics

1. Optimize for Throughput – flat heap collector focused on maximum throughput

2. Optimize for Pause Time – flat heap collector with concurrent mark and sweep to
minimize GC pause time
3. Subpool – a flat heap technique to help increase performance on multiprocessor
systems , commonly greater than 8. Available on IBM pSeries™ and zSeries™
4. Generational Concurrent – divides heap into “nursery” and “tenured” segments
providing fast collection for short lived objects. Can provide maximum throughput with
minimal pause times

ƒ Sun/HP JDK 5.0 Platforms

9 Garbage collector always Generational but implementation is chosen based on class of
system out of the box

1. Serial – Collects objects one at a time in both new and old generations
2. Throughput - Uses a parallel model for collecting objects in the new generation
3. Concurrent – Uses parallel collection in the new generation and concurrent in old.

21
Memory Management / Garbage Collection
How the IBM Mark and Sweep Garbage Collector Works

Wilderness
Thread B

Used HeapHeap
Thread Local
Stack Garbage
Used Heap
Collector
Global Heap
Heap lock Used Heap
Thread A
Thread Local Heap

Stack
System Heap Thread Local Heap
(JDK 1.4.2)

22
Memory Management / Garbage Collection
How the IBM J9 Generational and Sun/HP Garbage Collectors Work

JVM Heap

Nursery/Young Generation Old Generation Permanent Space

IBM J9: IBM J9: Sun JVM Only:

-Xmn (-Xmns/-Xmnx) -Xmo (-Xmos/-Xmox) -XX:MaxPermSize=nn
Sun: Sun:
-XX:NewSize=nn -XX:NewRatio=n
-XX:MaxNewSize=nn
-Xmn<size>

• Minor Collection – takes place only in the young generation, normally

done through direct copying Æ very efficient
• Major Collection – takes place in the old generation and uses the
normal mark and sweep algorithm
23
Memory Management / Garbage Collection
Fragmentation

ƒ Java Objects in the heap are in most cases moveable

9 In other words they are not tied to a single space in memory

ƒ Some objects in the heap however cannot be moved either permanently or

temporarily
9 Known as “pinned objects”

ƒ What does J9 do to prevent fragmentation

9 With the addition of new garbage collection strategies as well as a new
runtime memory management unit, pinned objects can be moved during
compaction and accounted for in a much better manner with JDK 5.0 thus
nearly eliminating the fragmentation problem seen in JDK 1.4.2 for the
most part.

24
Overview

ƒ JVM Basics

ƒ Overview of IBM’s J9 JVM

ƒ Memory Management / Garbage Collection

ƒ Runtime Performance Tuning

ƒ Debugging Tools

25
Runtime Performance Tuning
Overview

ƒ Tuning the JVM properly is a process that takes time and must be tailored to your
application.
9 HOWEVER you can typically get 80% of the maximum performance with 20%
of the work by ensuring that you are making good choice on a few key settings
9 To truly extract maximum performance from your application you must know
your applications memory allocation and runtime needs

ƒ The JVM must be tuned in two iterative steps over a testing cycle
9 Step 1: Heap Size tuning
9 Step 2: Applying runtime optimization
9 Applying these two steps repeatedly will lead you to a JVM tuned for your
application

26
Runtime Performance Tuning
Key Parameters

ƒ The key setting for the IBM JVM that effects performance most on all Java
application and should get you near 80% of your maximum performance if
set correctly is:
9 Heap Size (-Xms / -Xmx)
9 Ensure that you are setting your minimum and maximum to values that
are under you physical memory limitation but allow you to have a
substantially large interval between GC’s
• Typical low end bound on frequency of GC’s is 10sec
• Typical high end bound on duration of GC’s is 1-2sec

ƒ For the Sun/HP JVM a lot more work is required to get optimal performance
than just tuning the heap size as you need to tune the garbage collector and
runtime as well
9 A new JVM setting was introduced in JDK 1.4.1 that for Sun has shown
promise in automatically tuning the rest of heap settings for your machine
• -XX:+AggresiveHeap is issued at the command line and it makes
decisions on GC algorithms, Young/Old Generation spaces, and other
resources to use.
9 One must also issue the –server parameter to the Sun/HP JVMs to get
them to run in their highest performing mode.

27
Runtime Performance Tuning
What GC Policy should I choose for the J9 JVM?

ƒ I want my application to run to completion as quickly as possible.

9 -Xgcpolicy:optthruput

ƒ My application requires good response time to unpredictable events.

9 -Xgcpolicy:optavgpause

ƒ My application has a high allocation and death rate.

9 -Xgcpolicy:gencon

ƒ My application is running on big metal and has high allocation rates on

many threads.
9 -Xgcpolicy:subpool

28
Runtime Performance Tuning
Real world examples

WebSphere 6.1 - Trade 6

ƒ Some WebSphere applications 120

100
perform better with Generational 80
60
– however some applications 40
degrade in performance. 20
0
optthruput gencon

ƒ Customer may still be interested

WebSphere 6.1 - SPECjAppServer
in generational if it delivers lower
120
GC pause times. 100
80
60
40
20
0
optthruput gencon

Numbers are approximate and only intended to show a

general behaviour seen when running Trade6
compared to SPECjAppServer

29
Runtime Performance Tuning
Other IBM JVM Tuning Parameters

ƒ -Xgcthreads<n> (default is n-1 for n processors)

ƒ -Xnoclassgc - turns off class garbage collection (default is false)

ƒ -Xnocompactgc - turns off compaction which can lead to fragmentation (default is false)

ƒ -Xoss<size> - set the max Java stack size of any thread

ƒ -Xss<size> - set the max native stack size of any thread

ƒ -Xlp - enables large page support on supported Operating Systems

ƒ -Xdisableexplicitgc - turns System.gc() calls into no-ops

ƒ -Xifa:<on|off|force> - enables the Java code to run on z/OS zAAP processors

ƒ -Xmaxe / -Xmine - sets the maxium or minimum expansion unit during allocation

30
Runtime Performance Tuning
What GC Policy should I choose for the Sun JVM?

ƒ I want my application to concurrently with a lot of other JVM’s (hoteling).

9 Use default serial collector as the GC algorithm is single threaded

ƒ I need my application to perform good on a large number of processors.

9 -XX:+UseParallelGC

ƒ I need my application to return near constant response times on machines that

have a large number of processors.
9 -XX:+UseConcMarkSweepGC

ƒ I need my application to return near constant response times on machines that

have a small number of processors.
9 -XX:+UseTrainGC

31
Runtime Performance Tuning
Other Sun/HP JVM Tuning Parameters
ƒ -Xincgc - incremental GC, uses the Train algorithm (default is disabled)

ƒ -Xnoclassgc - disable class garbage collection

ƒ -Xss - set the stack size of each thread (512K)

ƒ -XX:+DisableExplicitGC - no System.gc() will be executed

ƒ -XX:TargetSurvivorRatio - sets threshold in survivor space for promotion to kick in

ƒ -XX:+UseAdaptiveSizePolicy - JVM determines good size for Eden, Survivor Spaces

ƒ -XX:+UseISM - allows for bigger pages (4MB)

ƒ -XX:+UseMPSS (used only for Solaris 9)

ƒ -XX:+AggressiveHeap -maximizes heap size and algorithms for speed

ƒ -Xoptgc - optimizes GC in Young Generation (HP only)

32
Runtime Performance Tuning
How to tune a generation GC setup – General

ƒ We need to consider the respective size of the nursery and the tenured
space.
ƒ Two approaches
9 Dynamic
• Specify the mininum and maxiumum heap size (e.g. –Xms512m –
Xmx1024m) and in the Sun JDK case -XX:+AggressiveHeap
• The JVM will dynamically size the nursery and tenured space.
• May not give optimal performance
• Could be good for low response times.
9 Fixed
• Be more specific on the nursery and/or tenured space sizes.
• Recommended approach for performance sensitive, server-side
applications.

33
Runtime Performance Tuning
How to tune a generation GC setup – Setting the tenured/old space

ƒ The tenured space must be large enough to hold all persistent data of
the application. Too small will cause excessive GC or even out of
memory conditions.
ƒ For a typical WebSphere Application Server application this is ~100-
400Mb.
ƒ One way to determine the tenure space size is to look at the amount of
free heap exists after each GC in default mode
9 %free heap x Total heap size

ƒ Analyse verbosegc to understand how frequently the tenured space

gets collected.
9 An optimal generational application will never have a collection in the
tenured space.
9 In the lab some WAS applications collect every ~15min.
34
Runtime Performance Tuning
How to tune a generation GC setup – Setting the nursery/new generation space

ƒ Large nursery Æ “good for throughput”

ƒ Small nursery Æ “good for low pause times”
ƒ Good WebSphere performance (throughput) requires a reasonable
large nursery.
• A good starting point would be 512 megabyte.
• Move up or down to determine optimal value.
– Measure throughput and/or response times
ƒ Analyse verbosegc to understand frequency and length of scavenges.

35
Tuning
Heap size options

ƒ Fix both nursery and tenured space

-XmnAm -XmoBm

Nursery Tenured
0 A 0 B

ƒ Allow them to expand/contract

-XmnsAm -XmnxBm -XmosBm -XmoxCm

A B C

36
Runtime Performance Tuning
Process for tuning heap settings

Set your
Performance
Give your best Tips
Tips
Start estimate for
Requirements mx and ms ••Run
Runyour
yourapplication,
application,
analyzeheap
analyze heapusage
usage
anddetermine
and determinethe the
Adjust mx steadystate.
steady state.
Stress test
and/or
your Setyour
Set your ms ms totothe
the
ms and possibly
application
switch GC steadystate.
steady state.
policy
••Make
Makesuresureyour
yourheap
heap
neverpages.
never pages.Monitor
Monitor
No yourpaging
your pagingactivities.
activities.
GC profile Analyze GC
Profile objects
If needed is good? behavior ••AArule
ruleof ofthumb
thumbisistoto
keep30%
keep 30%of ofyour
your
heapfree
heap freemost
mostof of
Yes
thetime.
the time.
Done.

37
Runtime Performance Tuning
Process for other runtime tuning settings
Set your
Tips
Tips
Set your
Start Performance
baseline
tuning
••Measure
Measurethroughput
throughput
Requirements
parameters duringsteady
during steadystate
stateof
of
thebenchmark
the benchmarkto to
ensureconsistent
ensure consistent
Stress test
results
results
Apply new
Tuning parameter
your
application
••Some
Sometuning
tuning
To runtime parameterswill
parameters willeffect
effect
performancenegatively
performance negatively
asthey
as theymight
mightbe be
targetedfor
targeted foranan
No
Remove tuning Is throughput as Analyze Runtime applicationwith
application withdifferent
different
behavior
Parameter if expected? runtimecharacteristics
runtime characteristics
Negative effect
thanyour
than yourapplication
application
Yes •• Add
Addonly
onlyone
onetuning
tuning
parameterat
parameter ataatime
timetoto
Done. measureits
measure itsimpact
impactalone
alone
38
Overview

ƒ JVM Basics

ƒ Overview of IBM’s J9 JVM

ƒ Memory Management / Garbage Collection

ƒ Runtime Performance Tuning

ƒ Debugging Tools

39
Debugging Tools
Garbage Collection Debugging/Analysis Tools (Verbose:GC)

Your most indispensable tool Æ directly from the JVM runtime

Enabled by issuing –verbose:gc on the java command line

Pros
9 can give a lot of detailed low-level information for serious debugging, enough
for initial investigation
9 readily available and it is free
Cons
9 Have to restart your server Æ not suitable for production environments
9 does not give object-level information for further analysis

40
Runtime Performance Tuning
Verbose:GC from J9
<af type="nursery" id="35" timestamp="Thu Aug 11 21:47:11 2005" intervalms="10730.361">
<minimum requested_bytes="144" />
<time exclusiveaccessms="1.193" />
<nursery freebytes="0" totalbytes="1226833920" percent="0" />
Allocation request
<tenured freebytes="68687704" totalbytes="209715200" percent="32" > details, time it took
<soa freebytes="58201944" totalbytes="199229440" percent="29" /> to stop all mutator
<loa freebytes="10485760" totalbytes="10485760" percent="100" /> threads.
</tenured>
<gc type="scavenger" id="35" totalid="35" intervalms="10731.054">
<flipped objectcount="1059594" bytes="56898904" /> Heap occupancy
<tenured objectcount="12580" bytes="677620" /> details before GC.
<refs_cleared soft="0" weak="691" phantom="39" />
<finalization objectsqueued="1216" />
<scavenger tiltratio="90" />
<nursery freebytes="1167543760" totalbytes="1226833920" percent="95" tenureage="14" />
Details about the
<tenured freebytes="67508056" totalbytes="209715200" percent="32" > scavenge.
<soa freebytes="57022296" totalbytes="199229440" percent="28" />
<loa freebytes="10485760" totalbytes="10485760" percent="100" />
</tenured>
<time totalms="368.309" /> Heap occupancy
</gc>
details after GC.
<nursery freebytes="1167541712" totalbytes="1226833920" percent="95" />
<tenured freebytes="67508056" totalbytes="209715200" percent="32" >
<soa freebytes="57022296" totalbytes="199229440" percent="28" />
<loa freebytes="10485760" totalbytes="10485760" percent="100" />
</tenured>
<time totalms="377.634" />
</af>

41
Debugging Tools
Garbage Collection Debugging/Analysis Tools – Sun/HP JVM verbose:gc output
-verbose:gc –XX:+PrintTenuringDistribution –XX:+PrintGCDetails –XX:+PrintGCStamps

ƒ Example:
ƒ 0.0000013: [Full GC 0.0005366: [Tenured: 0K->4185K(1380352K), 0.3102502 secs] 62984K->4185K(2057344K), 0.3103787 secs]

ƒ 236.661: [GC 236.661: [DefNew

ƒ Desired survivor size 61145088 bytes, new threshold 31 (max 31)
ƒ - age 1: 16817808 bytes, 16817808 total
ƒ - age 2: 20124840 bytes, 36942648 total
ƒ : 630283K->36076K(657088K), 0.7287377 secs] 666617K->72411K(2037440K), 0.7289491 secs]

ƒ 262.697: [GC 262.697: [DefNew

ƒ Desired survivor size 61145088 bytes, new threshold 31 (max 31)
ƒ - age 1: 15971824 bytes, 15971824 total
ƒ - age 2: 3806192 bytes, 19778016 total
ƒ - age 3: 18963992 bytes, 38742008 total
ƒ : 633452K->37833K(657088K), 0.6451270 secs] 669787K->74168K(2037440K), 0.6453326 secs]

ƒ 286.232: [GC 286.233: [DefNew

ƒ Desired survivor size 61145088 bytes, new threshold 31 (max 31)
ƒ - age 1: 17242304 bytes, 17242304 total
ƒ - age 2: 5131296 bytes, 22373600 total
ƒ - age 3: 2684464 bytes, 25058064 total
ƒ - age 4: 18728192 bytes, 43786256 total
ƒ : 635209K->42760K(657088K), 0.7164103 secs] 671544K->79094K(2037440K), 0.7166029 secs]

42
Debugging Tools
IBM JDK Debugging/Analysis Tools

ƒ Thread dumps
9 Available on all JVM’s by issuing kill -3 <pid> on the command line where
the<pid> is your servers process id
9 In essence a snap shot in time of what your system is executing. Used to
debug and find where threads are spending time in your system, or are hung in
your system

ƒ Heap dump
9 Can be enabled to occur with a thread dump by setting the following JVM
properties
• Click on Application Server -> server1 -> Process definition -> custom
properties ->
• Enter Name = IBM_HEAPDUMP
• Value = true
• Enter Name = IBM_JAVA_HEAPDUMP_TEXT (this enables generating
heapdump in txt format, which can be analyzed using heaproots)
• Value = true
9 Can be analyzed using HeapRoots at
http://www.alphaworks.ibm.com/tech/heaproots
43
Debugging Tools
IBM JDK Debugging/Analysis Tools

ƒ Class loader runtime diagnostics

9 -verbose:class – Gives you information about which classes are loaded
9 -Dibm.cl.verbose=<name> - Gives you specific information about how a class
name you define is attempted to me loaded.

ƒ Runtime Performance Analysis

9 A variety of third party tools will hook up to the IBM JVM to provide runtime
level profiling
• Jprobe, Jprofiler, etc
9 Hprof if built into the JDK as a profiler but is limited in function however still
good for debugging simple unit test case performance issues.

44
A few VERY useful URLs

ƒ http://www-106.ibm.com/developerworks/java/jdk/diagnosis/
9 Contains all the diagnostic guides for our JVMs
9 PDF on GC and Memory usage

ƒ http://java.sun.com/docs/performance
9 Contains a large amount of documentation and tuning for the Sun JVM
9 Reference to all SUN JVM flags as well as an explanation of them

ƒ http://www.hp.com/products1/unix/java/infolibrary/index.html
9 Wealth of information on tuning and configuring the HPUX JVM

45
 Thank you

Any questions ?

46
Backup and Extras

47
JVM Basics
The high level JVM Building Blocks – Part 1
IBM JVM

ƒ Core Interface – Encapsulates Core Interface (CI)

all interactions with user,
external programs and operating Execution Management (XM)
environment
Execution Engine (XE)

ƒ Execution Management –
Provides process control and
management
9 Threading engine resides here

ƒ Execution Engine - – Provides

all methods of executing Java
Byte Code both compiled and
48
interpreted.
JVM Basics
The high level JVM Building Blocks – Part 2
IBM JVM

ƒ Diagnostics – Encapsulates all Core Interface (CI)

debug and diagnostic services in
the JVM Execution Management (XM)
9 Tracing, FFDC, RAS, Debug
APIs Execution Engine (XE)

Diagnostics (DG) Class Loader (CL)

ƒ Class Loader – Provides
support for loading and Data Conversion
unloading of Java binaries
9 Performs loading, validation,
initialization, and implements
methods for reflection APIs

49

ƒ Data Conversion – Supports

JVM Basics
The high level JVM Building Blocks – Part 3
IBM JVM

ƒ Lock – Provides locking and Core Interface (CI)

synchronization services
Execution Management (XM)

ƒ Storage – Encompasses all Execution Engine (XE)

support for storage services the
JVM needs
Diagnostics (DG) Class Loader (CL)
9 Heap management, and
allocation strategies Data Conversion Lock (LK)

Storage (ST)
ƒ HPI – A set of well defined
functions that provide low level HPI
facilities and services in a
platform neutral way.
50

9 This interface is defined by

Memory Management / Garbage Collection
How the Sun/HP Garbage Collector Works – Part 2

-XX:SurvivorRatio=nn -XX:MaxTenuringThreshold=nn

Survivor Survivor
Eden
Space Space

Young Generation Old Generation Permanent Space

51