Improving Performance of Java Application – Part 1

Introduction

• There is a general perception that Java programs are slow.

• In early versions of Java, you had to struggle hard and compromise a lot to
make a Java application run quickly.
• The VM technology and Java development tools have progressed to the point
where a Java application is not particularly handicapped

Why is it slow ?

•The virtual machine layer that abstracts Java away from the underlying
hardware increase the
overhead.
• These overheads can cause Java application to run slower that an equivalent
application written in a lower-level language.
• Java's advantages . platform-independence, memory management, powerful
exception
checking, built-in multi-threading, dynamic resource loading and security checks
. add costs.

The tuning game

Performance tuning is similar to playing a strategy game (but happily, you are
usually paid to do it!). Your target is to get a better score (lower time) than the
last score after each attempt. You are playing with, not against, the computer,
the programmer, the design and architecture, the compiler, and the flow of
control. Your opponents are time, competing applications, budgetary restrictions,
etc. (You can complete this list better than I can for your particular situation.)

There is no such switch, but very simple techniques sometimes provide the
equivalent. Techniques include switching compilers, turning on optimizations,
using a different runtime VM, finding two or three bottlenecks in the code or
architecture that have simple fixes, and so on. These techniques provide huge
improvements to applications, sometimes a 20-fold speedup. Order-of-
magnitude speedups are typical for the first round of performance tuning.

System Limitations and What to Tune

Three resources limit all applications:

• CPU speed and availability

• System memory
 • Disk (and network) input/output (I/O)

When tuning an application, the first step is to determine which of these is

causing your application to run too slowly.

If your application is CPU-bound, you need to concentrate your efforts on the

code, looking for bottlenecks, inefficient algorithms, too many short-lived
objects.

If youpplication is hitting system-memory limits, it may be paging sections in

and out of main memory. In this case, the problem may be caused by too many
objects, or even just a few large objects, being erroneously held in memory; by
too many large arrays being allocated; or by the design of the application, which
may need to be reexamined to reduce its running memory footprint.

A Tuning Strategy

• 1. Identify the main bottlenecks (look for about the top five
bottlenecks)

• 2. Choose the quickest and easiest one to fix, and address it.

• 3. Repeat from Step 1.

Advantage :

Once a bottleneck has been eliminated, the characteritics of the application

change, and the topmost bottlenck may no need to be addressed any longer.

Identify bottleneck

1. Measure the performance by using profilers and benchmark suites.

2. Identify the location of any bottlenecks.

3. Think of a hypothesis for the cause of the bottleneck.

4. Consider any factors that may refute your hypothesis.

5. Create a test to isolate the factor identified by the hypothesis.

6. Test the hypothesis

7. Alter the application to reduce the bottleneck

8. Test that the alteration improves performance, and measure the improvement
9. Repeat from Step 1.

Perceived Performance

• The users has a particular view of performance that allows you to cut some
corners.

Ex : A browser that gives a running countdown of the amount left

to be downloaded from a server is seen to be faster that one
that just sits here until all the data is downloaded.

• Rules :
- if application is unresponsive for more than 2 sec, it is seem as slow.
- Users are not aware of response time improvements

How to appear quicker ?

•Threading : ensuring that your application remains reponsive to the user, even
while it is executing some other function.

• Streaming : display a partial result of the activity while continuing to compile

more results in background. (very useful in distributed systems).

• Caching : the caching technics help you to speed the data access. The read-
ahead algorithme use in disk hardware is fast when you reading forward through
a file.

Starting to tune

• User agreements : you should agree with your users what the performance of
the applications isexpected to be : response times, systemwide throughput,
max number of users, data, ...

• Setting benchmarks : these are precise specifications stating what part of code
needs to run in what amount of time. How much faster and in which parts, and
for how much effort ?

Without clear performance objectives, tuning will never be completed

Taking Measurements

• Each run of your benchmarks needs to be under conditions that are identical as
possible.

• The benchmark should be run multiples times, and the full list of results
retained, not just the average and deviation.
• Run a initial benchmark to specify how far you need to go and highlight how
much you have achieved when you finish tuning.

• Make your benchmark long enough (over 5 sec)

What to measure ?
• Main : the wall-clock time (System.currentTimeMillis())

• CPU time : time allocated on the CPU for a particular procedure

• Memory size
• Disk throughput
• Network traffic, throughput, and latency
Java doesn't provide mechanisms for measuring theses values directly.

Profiling Tools

• Measurements and timings

• Garbage collection
• Method calls
• Object-creation profiling
• Monitoring gross memory usage

Measurements and Timings

• Any profiler slow down the application it is profiling.

• Using currentTimeMillis() is the only reliable way.

• The OS interfere with the results by the allocation of different priorities to the
process.

• On certain OS, the foreground processes are given maximum priority.

• Some cache effects can lead to wrong result.

Garbage Collection

• Some of the commercial profilers provide statistics showing what the garbage
collector is doing.

• Or use the -verbosegc option with the VM.

• With VM1.4 : java -Xloggc:<file>

• The printout includes explicit synchronous calls to the garbage collector and
asynchronous executions of the garbage collector when free memory available
gets low.
• The important items that all -verbosegc output are
- the size of the heap after garbage collection
- the time taken to run the garbage collection
- the number of bytes reclaimed by the garbage collection.
• Interesting value :
- Cost of GC to your application (percentage)
- Cost of the GC in the application's processing time

GC Viewer

• Supported verbose:gc formats are:

- Sun JDK 1.3.1/1.4 with the option -verbose:gc

- Sun JDK 1.4 with the option -Xloggc:<file> (preferred)
- IBM JDK 1.3.0/1.2.2 with the option -verbose:gc

• GCViewer shows a number of lines :

- Full GC Lines: Black vertical line at every Full GC

- Inc GC Lines: Cyan vertical line at every Incremental GC
- GC Times Line: Green line that shows the length of all GCs
- Total Heap: Red line that shows heap size
- Used Heap: Blue line that shows used heap size

Method Calls

• Show where the bottlenecks in your code are and helping you to decide where
to target your efforts.

• Most method profilers work by sampling the call stack at regular intervals and
recording the methods on the stack.

• The JDK comes with a minimal profiler, obtain by using the -Xrunhprof option
(depends on theJDK). This option produces a profile data file (java.hprof.txt).

Object creation

• Determine object numbers

• Identifying where particular objects are created in the code.

• The JDK provides very rudimentary objectcreation statistics.

• Use a commercial tool in place of the SDK.

Monitoring Gross Memory Usage ?

• The JDK provides two methods for monitoring the amount of memory used by
the runtime system : freeMemory() and totalMemory() in the java.lang.Runtime
class.

• totalMemory() returns a long, which is the number of bytes currently allocated

to the runtime system for this particular VM process.

• freememory() returns a long, which is the number of bytes available to the VM

to create objects from the section of memory it controls.

Tools

• (commercial) Optimizeit from Borland

• (commercial) JProbe from Quest Software
• (commercial) JProfiler from ej-technologies
• (commercial) WebSphere Studio from IBM
• (free) HPjmeter from Hewlett-Packard
• (free) HPjtune

J2SE 5.0 Performance Features

• “Smart tuning”
• Small systems performance optimizations
• Client features

Class data sharing

Various JFC/Swing and Java 2D™ APIs improvements

• X86 Optimizations

JDK 5.0 release “Smart Tuning”

• Forget everything you just heard!

• Provide good “out-of-the-box” performance without hand tuning

• Examine host machine and configure Hotspot appropriately

• Dynamically adjust Java HotSpot VM software environment at runtime

• Simple tuning options based on application requirements not JVM software

internals

How “Smart Tuning” Works

•Determine type of machine JVM software is running on
• Server machine

Ø Larger heap
Ø Parallel garbage collector
Ø Server compiler

• Client machine

Ø Minimum heap
Ø Serial garbage collector
Ø Client compiler
• Adaptive Heap Sizing policy

Effects of “Smart Tuning”

Client Performance in 5.0

•Class data sharing
Ø Create class archive to share among multiple JVM machines
Ø Faster classload = faster startup time
Ø Shared class archive = reduced footprint
• JFC/Swing and Java 2D API improvements

Ø Better image management

Ø Font re-architecture
Ø Java Native Interface overhead improvements
Other Performance Enhancements in 5.0

•StringBuilder class
Ø Addition of StringBuilder class that works on an unsynchronized StringBuffer
for performance enhancement.
Ø You should replace all StringBuffer occurences with StringBuilder

•Java 2D technology

Ø Improved acceleration of BufferedImage objects. Support for hardware

accelerated rendering of OpenGL, and improved text rendering
performance

• Image I/O

Ø Performance and memory usage enhancements when reading and

writing JPEG files

J2SE 5.0 Platform Performance Tools

•Jconsole
Ø J2SE monitoring and management console
Ø JMX-compliant graphical tool for monitoring JVMs - both remote and local

• JPS

Ø JVM Process Status Tool

Ø Lists instrumented Hotspot VM on a target system

• Jstat
 Ø JVM Statistics Monitoring Tool
Ø Attaches to an instrumented Hotspot VM and collects the logs
Ø Performance stats as per the command line options

•Jstatd

Ø Launches an RMI server application that monitors for the creation and
termination of instrumented Hotspot VMs and provide an interface to allow
remote monitoring tools to attach to JVMs running on the local system