Memory Tuning in Java

IBM WEBSPHERE
TECHNICAL CONFERENCE
Bangalore, India
August 6 - 9, 2007
Session Number: W02

Tuning the Java Virtual Machine for Optimal Performance:
Means and Methods
Rajeev Palanki
IBM Java Technology Center
rpalanki@in.ibm.com
© 2007 IBM Corporation

Conference materials may not be reproduced in whole or in part without the prior written permission of IBM.
Objectives
• Have an insight into key aspects of JVM Runtime Performance and

understanding of the means and methods to tune the JVM for optimal
performance.
• At the end of this session you should have:
High level overview of the Java Virtual Machine (JVM) and its key components.
Understanding of different Garbage Collection schemas in the Sovereign & J9 Virtual Machines and
their impact on JVM Runtime performance.
Knowledge about using verbosegc outputs effectively to improve application response times.
Introduction to Shared Classes Technology and performance gains.
Familiarity with debugging and profiling tools available for JVM and their effective usage.
2007 WebSphere Technical Conference (Bangalore, India)

2
Agenda
• Overview of the Java Virtual Machine and its key components
• Garbage Collection Basics (Sovereign VM – 142 JDK)
• Profiling Garbage Collection: Verbosegc Outputs
• Garbage Collection Policies in Java 5.0
• Debugging and Analysis tools for Garbage Collection
• Introduction to Shared Classes Technology
• Real Time Java – A brief overview
• Q&A

3
IBM Java Building Blocks
Java SDK
Class Libraries JIT
Virtual Machine
Basic text slide

4
IBM Java Building Blocks
Big decimal
RAS
Java SDK
Class Libraries JIT
Security
ORB XML
GC
Virtual Machine

5
The Java Application Stack
ORB Java Code

Java Class Extensions
Java Class Libraries
Native Code
Core Interface (CI) Execution Management (XM)

Native
Execution libraries
Diagnostics Classloader
Engine
Storage
Lock Data
Conversion
JIT
HPI (Hardware Platform Interface)
Platform

6
Building Blocks
The JDK is a key component in the Application Server Stack from a performance perspective
– “Write Once Run Anywhere”

Application
– Class Libraries
– Collection of well-defined code packages that assist developers’
creation of business applications (3 specifications)
– Just-in-Time Compiler Class Libraries JIT
– Code generator that converts bytecodes into machine language
instructions at run time. Java SDK
– Virtual Machine
– Platform independent execution environment that abstracts
operating system specifics from the developer/user.
Virtual Machine
– Vendor specific operating environment

Operating system
– Specific hardware architecture (instruction set)

7
IBM Java 5.0
• IBM have totally rewritten and redesigned our VM for Java 5.0 – You may have
heard this referred as J9
New Virtual Machine implementation (J9)

New Garbage Collection Mechanism (Modron)
New Just In Time Compiler (Testarossa)
Shared Classes technology
• Just In Time Compiler (Testarossa)
Multiple optimization levels

Recompilation driven by sampling thread
Dynamic Profile Information Collection
Profiling thread helps determine “hotness” of methods
Asynchronous compilation
• Garbage Collection (Modron)
Uses a “type accurate” collector

Introduces parallel compactor
Introduces “Generational GC” policy
8
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

Frequency depends on the heap size and allocation rate
Duration depends on the heap size and number of objects in the heap
¾ GC algorithm
Critical to understand how it works so that tuning is done more intelligently.
¾ How do you eliminate GC bottlenecks?

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

9
The (IBM) JVM Garbage Collector
• “The purpose of Garbage Collection is to identify Java Heap storage which is no

longer being used by the Java application and so is available for reuse by the
JVM”
•Key questions:
•Performance and Scalability: How quickly can you find garbage?
•Accuracy: Can you find all the garbage?
•Effectiveness: How much space can you make available?

10
Garbage Collection: IBM Technology
• Concurrent mark
Most of the marking phase is done outside of ‘Stop the World’ when the ‘mutator’ threads are
still active giving a significant improvement in pause time.
• Parallelizing the garbage Collection phases
The Mark and sweep workload is distributed across available processors resulting in a
significant improvement in pause times
• Adaptive sizing of thread local heaps
Reduces the amount of Java Heap locking
• Incremental compaction
The expense of compaction is distributed across GCs leading to a reduction in (an occasional)
long pause time.
• Java 5 technologies
Lazy sweep, parallel compaction, generational and accurate collection

11
The JVM Heaps
freelist
Native Heap
Size
Java Heap Next
Size
free storage
Next
Null
free storage
JIT Compiled Code

Free List
Motif structures
‘
Thread Stacks Xms - Active Area of Heap
Buffers

12
Allocation schemes
• Two types of allocation
– Cache Allocation (for object allocations < 512 bytes), does not require Heap
Lock. Each thread has local storage in the heap (TLH – Thread Local Heap)
where the objects are allocated.
– Heap Lock Allocation (Heap Allocation occurs when the allocation request is
more than 512 bytes, requires Heap Lock.
If size is less than 512 or enough space in the cache

try cacheAlloc
return if OK
HEAP_LOCK
do forever
If there is a big enough chunk on freelist
Take it
goto Gotit
else
manageAllocFailure
If any error
goto GetOut
End do
Gotit:
Initialize object
Get out
Heap_UNLOCK

13
Large Object Allocation
• All objects => 64K are termed “large” from the VM

perspective Active heap
• In practice, objects of 10MB+ in size are usually

considered large
LOA
• The Large Object Area is 5% of the active heap by
default.
• Any object is first tried to be allocated in the free list of
the main heap – if there is not enough “contiguous” Xmx
space in the main heap to satisfy the allocation request
for object => 64K, then it is allocated in the Large
Object Area (wilderness)
• Objects < 64K can only be allocated in the main heap
and never in the Large Object Area
Users can identify the Java stack of a thread making an
allocation request of larger than the value specified with
the environment variable ALLOCATION_THRESHOLD
export ALLOCATION_THRESHOLD =5400

This will give java stacks for object allocations of created
than 5400 bytes.
Users can specify the desired % of the Large Object Area using the Xloration option (where n determines the
fraction of heap designated for LOA.
(For example: Xloratio0.3 reserves 30% of the active heap for the Large Object Area)

14
Sub pools
• Subpools provide an improved policy of object allocation and is available

from JDK 1.4.1 releases only on AIX.
– Improved time for allocating objects

– Avoid premature GCs due to allocation of large objects
– Improve MP scalability by reducing time under HEAP_LOCK
– Optimize TLH sizes and storage utilization
• The subpool algorithm uses multiple free lists rather than the single free list
used by the default allocation scheme.
• It tries to predict the size of future allocation requests based on earlier

allocation requests. It recreates free lists at the end of each GC based on
these predictions.
• While allocating objects on the heap, free chunks are chosen using a ″best
fit″ method, as against the ″first fit″ method used in other algorithms.
• It is enabled by the –Xgcpolicy:subpool option.
• Concurrent marking is disabled when subpool policy is used.

15
Garbage Collection Basics (142 JVM)
• Garbage Collection is performed when there is:
¾ An allocation failure in the heap lock allocation

¾ Specific call to System.gc
• Garbage Collection is Stop the World (All other application threads are suspended during
GC)
• Two main technologies used to remove garbage:
¾ Mark Sweep Collector

¾ Copy Collector
GC occurs in the thread that handled the request
¾ Requested object allocation that caused allocation failure

¾ Programmatically requested GC
• Thread must acquire certain locks required for GC
¾ Heap Lock
¾ Thread queue lock
¾ JIT lock

16
Object reclamation process for a Mark Sweep Collector
Obtain locks and suspend threads
Mark phase
Process of identifying all objects reachable from the root set.
All “live” objects are marked by setting a mark bit in the mark bit vector.
Sweep phase
¾ Sweep phase identifies all the objects that have been allocated, but no longer
referenced.
Compaction (optional)
¾ Once garbage has been removed, we consider compacting the resulting set of
objects to remove spaces between them.
Release locks and resume threads

17
Mark – Sweep – Compact Algorithm
reachable Root Set

object
unreachable
object
Heap

18
Together we achieve: Some parallel processing
• GC Helper threads
On a multiprocessor system with N CPUs, a JVM supporting parallel mode starts N-1
garbage collection helper threads at the time of initialization.
These threads remain idle at all times when the application code is running; they are
called into play only when garbage collection is active.
For a particular phase, work is divided between the thread driving the garbage
collection and the helper threads, making a total of N threads running in parallel on
an N-CPU machine.
The only way to disable the parallel mode is to use the -Xgcthreads parameter to
change the number of garbage collection helper threads being started.
• Parallel Mark
The basic idea is to augment object marking through the addition of helper threads
and a facility for sharing work between them.
• Parallel BitWise Sweep

Similar to parallel mark, uses same helper threads as parallel mark
Improves sweep times by using available processors.

19
Concurrent Marking
Designed to give reduced and consistent GC pause times as heap sizes

increases.
Concurrent aims to complete the marking just before the before the heap is
full.
In the concurrent phase, the Garbage Collector scans the roots by asking each
thread to scan its own stack. These roots are then used to trace live objects
concurrently.
Tracing is done by a low-priority background thread and by each application

thread when it does a heap lock allocation.
Concurrent is enabled by the option: -Xgcpolicy:optavgpause

20
Incremental Compaction
• Incremental compaction removes the dark matter from the heap and reduces pause times
significantly
• The fundamental idea behind incremental compaction is to split the heap up into sections and
compact each section just as during a full compaction.
• Incremental compaction was introduced in JDK 1.4.0; is enabled by default and triggered under
particular conditions. (Called Reasons)
• -Xpartialcompactgc Option to invoke incremental compaction in every GC cycle.

• -Xnopartialcompactgc Option to disable incremental compcation.
• -Xnocompactgc Option to disable full compcation
The heap is divided into regions

The regions are further divided into sections
Each section is handled by one helper thread
A region is divided into
(number of helper threads +1) or
8 sections (whichever is less)
The whole heap is covered in a few GC cycles.

21
Explicit Garbage Collection
Garbage collector is called only upon two conditions:
When an allocation failure occurs

GC explicitly called using System.gc
Don’t call System.gc() at all. It hurts more often than it helps. GC

knows when it should run
The temptation to scatter System.gc() calls here, there, and

everywhere is enormous. It does not make a good idea.
TRUST ME !!!!!
Use –Xdisableexplicitgc to avoid running GC for each System.gc().

22
Profiling Garbage Collection: Verbosegc output
The most indispensable tool for profiling GC activity is

Verbosegc – from JVM runtime.
Enabled using –verbosegc on the java command line.
Verbosegc redirection
-Xverbosegclog: <path to file> filename
Verbosegc redirection to multiple files

-Xverbosegclog:<path to file>filename#,X,Y
(Redirect to Y files each containing X GC cycles)

23
Understanding a typical verbosegc output
<AF[71]: Allocation Failure. need 65552 bytes, 3 ms since last AF>

<AF[71]: managing allocation failure, action=2 (142696/10484224)>
<GC(71): GC cycle started Fri Mar 19 17:59:06 2004
<GC(71): freed 94184 bytes, 2% free (236880/10484224), in 12 ms>
<GC(71): mark: 5 ms, sweep: 0 ms, compact: 7 ms>
<GC(71): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<GC(71): moved 3095 objects, 188552 bytes, reason=1>
JVMDG217: Dump Handler is Processing a Signal - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to
/workarea/rajeev/gctests/heapdump.20040319.175906.8467.txt
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to
/workarea/rajeev/gctests/javacore.20040319.175906.8467.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[71]: insufficient heap space to satisfy allocation request>
<AF[71]: completed in 203 ms>

24
When are GC messages printed out?
• The first two lines are put out just before the beginning of STW phase of GC.
• Rest of messages are printed out after the STW phase ends and threads are
woken up. No messages are printed during GC.
• Heap shrinkage messages are printed before STW messages, but shrinkage
happens AFTER STW phase!
• Heap expansion messages are correctly printed AFTER STW messages.
(STW = Stop The World)

25
Things to look for in a verbosegc output
• Was it an Allocation Failure GC?
• What was the size of allocation request that caused AF?
• What were the total and free heap sizes before GC?
• What was the total pause time?
• Where was maximum time spent in GC?
• Are we doing a compaction in each GC cycle?
• What actions were taken by GC?
• Was GC able to meet allocation request in the end?
• What was the free heap size after GC?

26
GC actions (JDK 142)
• Look for lines of this type:
managing allocation failure, action=<n>
Where <n> is the numerical value of action taken.
Actions:
0 -> GC because of exhaustion of pinned free list.
1 -> Perform garbage collection without using

wilderness
2 -> Garbage Collector tried to allocate out of wilderness and

failed.
3 -> Expand the Java heap
4 -> Clear soft references
5 -> Steal space from transient heap (zOS only)
6 -> Couldn’t get enough space. Print appropriate messages.

27
Using verbosegc to set the heap size
• Use verbosegc to guess ideal size of heap, and then tune using –Xmx and –Xms.
• Setting –Xms:
Should be big enough to avoid AFs from the time the application starts to the time it
becomes ‘ready’. (Should not be any bigger!)
• Setting –Xmx:
In the normal load condition, free heap space after each GC should be > minf (Default
is 30%).
There should not be any OutOfMemory errors.
In heaviest load condition, if free heap space after each GC is > maxf (Default is 70%),
heap size is too big.

28
Example of verbosegc when heap is too small
GC is too frequent
<GC(25): GC cycle started Sat Mar 20 15:32:50 2004
<GC(25): freed 3968 bytes, 3% free (323424/10484224), in 11 ms>
<GC(25): moved 214 objects, 9352 bytes, reason=1>
<AF[25]: warning! free memory getting short(1). (323424/10484224)>

29
Example of verbosegc when heap is too big
GC is too long
<AF[29]: managing allocation failure, action=1 (3235443800/20968372736)
(3145728/3145728)>
<GC(29): GC cycle started Mon Nov 4 14:46:20 2002
<GC(29): freed 8838057824 bytes, 57% free (12076647352/20971518464), in
4749 ms>

30
Effect of wrong –Xms & -Xmx settings
Too small heap = Too frequent GC.
Too big heap = Too much GC pause time. (Irrespective of amount of physical memory on the
system)
Heap size > physical memory size = paging/swapping = bad for your application.
It is desirable to have the Xms much less than Xmx if you are encountering fragmentation issues.
This forces class allocations, thread and persistent objects to be allocated at the bottom of the
heap.
What about Xms=Xmx?

It means no heap expansion or shrinkage will ever occur.
Not normally recommended.
It may be good for a few apps which require constant high heap storage space.
Hurts apps which show a varying load.
May lead to more fragmentation

31
Mark Stack Overflow (MSO)
• Verbosegc will contain the line:

<GC(45): mark stack overflow>
• Is bad for performance.
• Caused by too many objects on the heap, especially deeply nested objects.
• Processing MSOs is expensive
• No solution is a silver bullet. Things to try:
¾ Decrease the heap size!

¾ Use concurrent mark (-Xgcpolicy:optavgpause)
¾ Re-design the application.
¾ Increase GC helper threads (-Xgcthreads<n>)

32
High pause times and system activity
In the event of pause times being usually acceptable with the exception of a few
"abnormally high" spikes - we are likely to infer that the deviation was a result of
some system level activity (heavy paging for ex) outside of the Java process.
Consideration: How many clock ticks our process actually spent executing
instructions, not time spent waiting for I/O or time spent waiting for a CPU to
become available for the process to run on?
Profile system level activity

33
Headline Changes in Java 5.0 Garbage Collector
Java Tiger: JSE 5.0
¾ 5.0 uses a completely new memory management framework
¾ No pinned/dosed objects
Stack Maps used to provide a level of indirection between references and heap
5.0 VM never pins arrays, it always makes a copy for the JNI code
¾ The GC is Type Accurate
¾ New efficient parallel compactor
¾ -Xgcpolicy:optavgpause includes concurrent sweeping (as well as marking)

34
Garbage collection policies in IBM Java 5.0
• Four policies available:
Optthruput (default)
¾ Mark-sweep algorithm
¾ Fastest for many workloads
optavgpause
¾ Concurrent collection and concurrent sweep
¾ Small mean pause
¾ Throughput impact
gencon
¾ The Generational Hypothesis
¾ Fastest for transactional workloads
¾ Combines low pause times and high throughput
subpools
¾ Mark-sweep based, but with multiple freelists
¾ Avoids allocation contention on many-processor machines
¾ Available on all PPC and S390 platforms

35
Why different GC Policies?
• Availability of different GC policies gives you increased capabilities.
• Best choice depends upon application behaviour and workloads.
• Think about throughput, response times & pause times.
Policy Option Description

( -Xgcpolicy )
Throughput is the amount of
data processed by the It is typically used for applications where
application Optimize for Optthruput raw throughput is more important than
throughput short GC pauses. The application is
(Default) stopped each time that garbage is
Response time is the latency collected.
of the application – how
quickly it answers incoming
requests Optimize for Optavgpause Trades high throughput for shorter GC
pause times pauses by performing some of the
garbage collection concurrently. The
Pause time is the amount application is paused for shorter times.
of time the garbage Generational gencon Handles short lived objects differently than
collector has stopped Concurrent the longer lived.
threads while collecting the
heap.
Supool subpool Uses same algorithm similar to the default

policy but employs allocation strategy
suitable for SMPs.

36
Runtime Performance Tuning
What policy should I choose for my J9 VM
Policy Considerations
optthruput I want my application to run to completion as quickly as possible.
optavgpause • My application requires good response times to unpredictable events.
• A degradation in performance is acceptable as long as GC pause times are reduced.
• My application is running very large java heaps.
• My application is a GUI application and user response times are important.
gencon • My application allocates many short lived objects
• The java heap space is fragmented
• My application is transactions based
Subpool I have scalability concerns on large multiprocessor machines.

37
Memory Management / Garbage Collection
How the IBM J9 Generational Garbage Collector Works
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 new and old generation and uses
the normal mark/sweep (+compact) algorithm
38
Nursery/Young Generation
Nursery/Young Generation
Survivor Space
Allocate Space Allocate
Survivor Space
Space
• Nursery is split into two spaces (semi-spaces)

Only one contains live objects and is available for allocation
Minor collections (Scavenges) move objects between spaces
Role of spaces is reversed
• Movement results in implicit compaction

39
Sample verbosegc output for gencon
<af type="nursery" id="35" timestamp="Thu Aug 11 21:47:11 2005" intervalms="10730.361">

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

40
Diagnostic tool for garbage collector
• Diagnostic tool for optimizing parameters affecting the
garbage collector while using IBM JVM
• Reads the “verbosegc” output and produces textual and

graphical visualizations and related statistics
– Frequency of garbage collection cycles

– Time spent in different phases of garbage collection
– Quantities of heap memories involved in the
process
– Characteristics of allocation failures
– Mark Stack Overflows
• Built in parsers for JVM 1.5, 1.4.2 , 1.3.1 & 1.2.2
• Prerequisite – JFreeChart libraries (freely downloadable)
• http://www.alphaworks.ibm.com/tech/gcdiag

41
Screen Shots
Starting the tool and selecting verbosegc input file and appropriate JVM parser
Extract GCCollector.zip
Place jfreeChart-0.9.21.jar and jcommon-0.9.6.jar in the lib directory of the GCCollector folder
Execute GCCollector.bat (which will spawn a GUI)
Select verbosegc file for analysis
Select appropriate JVM parser

42
Duration of GC Cycles – Graphical View

43
Graphical view of heap usage

44
Information for specific cycle

45
Choosing time range

46
Extensible Verbose Tool Kit
Analyzing your verbose GC output
• EVTK: Verbose GC visualizer and analyzer

Available through ISA
¾ IBM Support Assistant v3.0.2
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=isa
Reduces barrier to understanding verbose output

¾Visualize GC data to track trends and relationships
¾ Analyze results and provide general feedback
¾ Extend to consume output related to application
¾ Build plug-able analyzers for specific application needs

47
Starting the EVTK
In the Tools
section of ISA,
select the Java
product plug-in to
display the
available tools
Click on the
name of a tool to
start that tool

48
EVTK usage scenarios
• Investigate performance problems

Long periods of pausing or unresponsiveness
• Evaluate your heap size

Check heap occupancy and adjust heap size if needed
• Garbage collection policy tuning

Examine GC characteristics, compare different policies
• Look for memory growth

Heap consumption slowly increasing over time
Evaluate the general health of an application

49
Extensible Verbose Toolkit overview
• The Extensible Verbose Toolkit (EVTK) is a visualizer for verbose

garbage collection output
The tool parses and plots verbose GC output and garbage collection traces (-Xtgc
output)
• The tooling framework is extensible, and will be expanded over time to

include visualization for other collections of data
• The EVTK provides
Raw view of data

Line plots to visualize a variety of GC data characteristics
Tabulated reports with heap occupancy recommendations
View of multiple datasets on a single set of axes
Ability to save data as an image (jpeg) or comma separated file (csv)

50
Plotting data with the EVTK
Use File > Open The VGC Data

to open a new menu allows
input file you to choose
what data to
Use File > Add display
to add multiple
input files to a
single data set
for comparison The Axes
and aggregated panel supports
display customized
units and pan-
and-zoom
Right-click on the
plot and use the
context menu to The Line plot tab contains
export data the data visualization

51
Reports and recommendations
• Report contents can be

configured using VGC menu
options
Occupancy recommendations
tell you how to adjust heap size
for better performance
Summary information is
generated for each input in the
dataset
Graphs included for all GC
display data
• Can export as HTML by right-
clicking and using the context
menu The Report tab contains the
report for the current dataset

52
Types of graphs
• The EVTK has built-in support for over forty different types of graphs
These are configured in the VGC Data menu
Options vary depending on the current dataset and the parsers and post-
processors that are enabled
• Some of the VGC graph types are:
• Used total heap • Free tenured heap (after collection)
• Pause times (mark-sweep-compact • Tenured heap size
collections) • Tenure age
• Pause times (totals, including exclusive • Free LOA (after collection)
access) • Free SOA (after collection)
• Compact times • Total LOA
• Weak references cleared • Total SOA
• Soft references cleared
• Note: Different graph types and a different menu are available for TGC
output

53
Heap usage and occupancy
recommendation
The summary report shows

that mean heap occupancy is
98% and that the application
is spending over a third of its
time doing garbage collection
This graph shows heap

usage after garbage
collection; it jumps up to
around 60M and stays there

54
EVTK – Heap Visualization
Heap occupancy
Pause times
55
EVTK - Comparison & Advice
Compare runs…
Performance advisor…
56
Java 5 Shared Classes
• Available on all platforms.
• Feature enabled using the –Xshareclasses flag.
• Static class data caches in shared memory

Shared between all IBM Java VMs
All application and bootstrap classes shared
Cache persisted beyond lifetime of any JVM, but lost on shutdown/reboot
• Provides savings in footprint and start up times.
• Target: Server environments where multiple JVMs exist on the same box.
• Multiple sharing strategies

Standard Classloaders (including Application Classloader) exploit this feature when enabled.
API to extend Customer Classloaders available.

57
Shared Classes – Start up times
Startup Improvements with Shared Classes and AOT
Sharing
30 helps speed up JVM startup
25
default
20
Seco n d s
15
-Xshareclasses
(Java 5.0)"
10
-Xshareclasses
5 (Java 6.0)
0
eclipse 3.2.2 tomcat 5.5 WAS 6.1
Lower is better
58
What does real-time mean?
• Real-time = predictability of performance

Hard - Violation of timing constraints are hard failures
Soft - Timing constraints are simply performance goals
• Constraints vary in magnitude (microseconds to seconds)
• Consequences of missing a timing constraint:

from service level agreement miss (stock trading)
to life in jeopardy (airplanes)
• Real-fast is not real-time, but Real-slow is not real-good
• Need a balance between predictability and throughput

59
WebSphere Real Time (WRT)
• 1.0 generally available in August 2006.
• WRT is a Java runtime providing highly predictable operation

Real-time garbage collection (Metronome)
Static and dynamic compilation
Full support for RTSJ (JSR 1)
Java SE 5.0 compliant
Built and rigorously tested on a RT Linux OS with IBM Opteron Blades

60
Real-Time Garbage Collection
The Metronome Garbage Collector
• Utilization
Percentage of time dedicated to the application in a
given window of time Time
Application
Collector 10ms Application receives a minimum

percentage of time to run
• Metronome uses a 10ms sliding window to

measure utilization
Utilization is user selectable via command line

61
Visual Performance Analyser
• Eclipse based performance visualization kit

– Profile Analyzer
– Code Analyzer
– Pipeline Analyzer
• Profiler Analyzer provides a powerful set of graphical and text-based views that
allow users to narrow down performance problems to a particular process,
thread, module, symbol, offset, instruction or source line.
– Supports time based system profiles
• Code Analyzer examines executable files and displays detailed information

about functions, basic blocks and assembly instructions.
• Pipeline Analyzer displays the pipeline execution of instruction traces.
• http://www.alphaworks.ibm.com/tech/vpa

62
Profile Analyzer Views
• The following are important views within Profile Analyzer:

Basic Blocks
Call-Graph Callers/Descendants
Compiler Listing
Console
Counters
Database Connections
Disassembly/Offsets
Disassembly Comparison
Java/Classes Hierarchy
Profile Comparison
Profile Details
Profile Resources
Resolved Calls
Sample Distribution Chart
Source Code
Symbol Distribution
Temporal Profiling

63
Temporal Profiling View

64
Counters : In the Process Hierarchy View
( View Window -> Show View -> Others
-> Profile Analyzer -> Counters)

65
Summary
• Take Aways from the Session:
High level overview of the Java Virtual Machine (JVM) and its key
components.
Understanding of different Garbage Collection schemas in the Sovereign &

J9 Virtual Machines and their impact on JVM Runtime performance.
Knowledge about using verbosegc outputs effectively to improve application

response times.
Introduction to Shared Classes Technology and performance gains.
Familiarity with debugging and profiling tools available for JVM and their
effective usage.

66
References & Further Reading
• www.ibm.com/developerworks/java/library/j-ibmjava2
• developers.sun.com/learning/javaoneonline/2007/pdf/TS-
2023.pdf
• http://www.ibm.com/developerworks/java/library/j-
ibmjava4/
• http://www-128.ibm.com/developerworks/java/library/j-
rtj1/index.html
• https://www-
950.ibm.com/events/IBMImpact/Impact2007/3977.pdf

67
Questions ?

68
Thai
Hindi
Traditional Chinese
Gracias
Merci
Russian Spanish
French
Obrigado
Thank You English
Brazilian Portuguese
Arabic
Danke
German
Grazie Simplified Chinese

Italian
Japanese
Tamil Korean
Teşekkürler
turkish

69
Session Evaluation
• Please complete your session evaluation

• Thank you

70

Memory Tuning in Java

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Memory Tuning in Java

Caricato da

Copyright:

Formati disponibili

IBM WEBSPHERE

Session Number: W02

© 2007 IBM Corporation

• Have an insight into key aspects of JVM Runtime Performance and

• At the end of this session you should have:

 Introduction to Shared Classes Technology and performance gains.

2007 WebSphere Technical Conference (Bangalore, India)

• Overview of the Java Virtual Machine and its key components

• Garbage Collection Basics (Sovereign VM – 142 JDK)

• Profiling Garbage Collection: Verbosegc Outputs

• Garbage Collection Policies in Java 5.0

• Debugging and Analysis tools for Garbage Collection

• Introduction to Shared Classes Technology

• Real Time Java – A brief overview

2007 WebSphere Technical Conference (Bangalore, India)

Basic text slide

2007 WebSphere Technical Conference (Bangalore, India)

ORB Java Code

Core Interface (CI) Execution Management (XM)

2007 WebSphere Technical Conference (Bangalore, India)

– “Write Once Run Anywhere”

– Vendor specific operating environment

2007 WebSphere Technical Conference (Bangalore, India)

 New Virtual Machine implementation (J9)

• Just In Time Compiler (Testarossa)

 Multiple optimization levels

• Garbage Collection (Modron)

 Uses a “type accurate” collector

¾ Garbage Collection (GC)

 The main cause of memory–related performance bottlenecks in Java.

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

¾ How do you eliminate GC bottlenecks?

2007 WebSphere Technical Conference (Bangalore, India)

• “The purpose of Garbage Collection is to identify Java Heap storage which is no

•Performance and Scalability: How quickly can you find garbage?

•Accuracy: Can you find all the garbage?

•Effectiveness: How much space can you make available?

2007 WebSphere Technical Conference (Bangalore, India)

• Parallelizing the garbage Collection phases

• Adaptive sizing of thread local heaps

Reduces the amount of Java Heap locking

Lazy sweep, parallel compaction, generational and accurate collection

2007 WebSphere Technical Conference (Bangalore, India)

JIT Compiled Code

2007 WebSphere Technical Conference (Bangalore, India)

• Two types of allocation

If size is less than 512 or enough space in the cache

2007 WebSphere Technical Conference (Bangalore, India)

• All objects => 64K are termed “large” from the VM

• In practice, objects of 10MB+ in size are usually

export ALLOCATION_THRESHOLD =5400

2007 WebSphere Technical Conference (Bangalore, India)

• Subpools provide an improved policy of object allocation and is available

– Improved time for allocating objects

• It tries to predict the size of future allocation requests based on earlier

• Concurrent marking is disabled when subpool policy is used.

2007 WebSphere Technical Conference (Bangalore, India)

• Garbage Collection is performed when there is:

¾ An allocation failure in the heap lock allocation

• Two main technologies used to remove garbage:

¾ Mark Sweep Collector

GC occurs in the thread that handled the request

Introduction to Shared Classes Technology and performance gains.

New Virtual Machine implementation (J9)

Multiple optimization levels

Uses a “type accurate” collector

The main cause of memory–related performance bottlenecks in Java.

Obtain locks and suspend threads

Release locks and resume threads

Designed to give reduced and consistent GC pause times as heap sizes

Tracing is done by a low-priority background thread and by each application

Concurrent is enabled by the option: -Xgcpolicy:optavgpause

The heap is divided into regions

Garbage collector is called only upon two conditions:

When an allocation failure occurs

Don’t call System.gc() at all. It hurts more often than it helps. GC

The temptation to scatter System.gc() calls here, there, and

Use –Xdisableexplicitgc to avoid running GC for each System.gc().