Performance Tuning Java Apps

see also WebSphere and Their JVM

System Level Metrics


Garbage Collection

Core Measures

The percentage of time *NOT* spent in the garbage collector (how much actual processing time the JVM does)
Are there significant pauses caused from garbage collecting?
How much overall memory is required by the app?
How much time lapses between when an object dies and when the memory is available for use.


Java Connector Architecture
JVM Performance Interface
Mixed-Method Invocation — a mode where the JVM interprets some byte-code and compiles others depending on how many times a method has been called. (IBM-only)
Native ? Thread Library (wikipedia article here)
Thread-Local Heap

Good Article

I lifted the following article from here.

This is a common issue that has also been noted on the hibernate forums, among

The JVM allocates a certain amount of its total memory to 3 basic areas:
i) Young generation (YoungGen) - this is for objects that only live for a few
hundred milliseconds to a couple of seconds, at the most.
ii) Old generation (OldGen) - this is for longer living objects - when the
garbage collector does a sweep over the YoungGen, any unclaimable objects are
moved to the OldGen area. When the OldGen area starts to fill up, the garbage
collector will occasionally do a full GC, which also attempts to reclaim any
memory it can from the OldGen as well.
iii) Permanent Generation (PermGen) - This is for permanent memory allcoation,
and is used to store mainly java class information.

PermGen space is NOT garbage collected, so the more classes you load, the more
it fills up. For most applications this hardly causes any problems, but when
you have applications that dynamically create java classes, you have a
situation where over time the PermGen space will start to use up more memory
than it would have for all statically compiled classes.

Moreover, PermGen space very often is not cleaned out properly during web
application reload, with some certain notable offenders (Commons Logging,
java.sql.DriverManager), holding static references to their own class files,
thus preventing class unloading. So the memory usage just goes up and up with
subsequent reloads.

Some frameworks/java libraries that dynamically create java class files (that
I know of) include:
i) JSP
ii) JDK Proxy (used by Spring and others)
iii) CGLib (used by Spring and Hibernate and some JDO implementations),
iv) Javassist (used by JBoss and Tapestry)

So the problem here is that for a large web application (such as I have)
consisting of Tapestry pages, with Spring services, and Hibernate back-end,
you have a requirement for more than the default PermGen memory in your
servlet container. The good news, though, is that provided you haven't done
something irresponsible like disable page caching in production, there IS an
upper limit on the classes that will be dynamically generated.

You can increase PermGen size by adding this to your jvm parameters:
-XX:MaxPermSize=??M (where ?? is some memory value like 64 or 128)

If you want to see the garbage collector in action, add this to your jvm
-Xloggc:gc.out -XX:+PrintGCDetails

Lastly, on the subject of webapp reload. The servlet specs do not require a
servlet container to support webapp reload. So don't treat it as a right. I
only use the reload feature in development only, or on simple webapps only in
production. But if I'm updating a large webapp that uses
Tapestry+Spring+Hibernate, I pick a quiet time of the day (or night) and
restart Tomcat. It causes so much less hassle.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License