views:

419

answers:

4

Recent JVM's have a lot of XX parameters for garbage collection (see here for example), but what are the options which can make a client side Swing application really perform better?

I should note that one of the things that really annoys me on client side java applications is the large delay in stop-the-world garbage collection. In Intelli-J IDEA I have seen it go three minutes or more.

EDIT: Thanks for all the responses. Just to report back I put on the CMS garbage collector for IDEA (which is a good common reference of the type of application that most everyone reading this question is familiar with) using the setting's suggested from here. I also set -XX:+StringCache to see if it would reduce memory requirements.

In general, the observation is that regular running performance is not degraded to the point where you can notice looking at it. The memory reduction is huge using the String Cache option, however the CMS method is not thorough and ends up requiring a stop the world garbage collection cycle (back to the three minute wait) to clear out the memory (400MB in one run).

However, given the reduced memory footprint, I might be able to just put a smaller maximum amount of memory which will keep the stop the world collections smaller in sizes.

IDEA 8.1.4 comes with JDK 1.6.0_12, so I didn't test G1 yet. Also, my machine only has 2 cores, so a G1 approach won't really be maximized. Time to hit the boss up for a better machine ;).

+3  A: 

Garbage collection tuning is more than an art then science, and it really depends on your application and its usage. If the standard stop-the-world strategies bother you, why not convert to the CMS (concurrent mark and sweep) or the new G1 collector?

The best way is to change the parameters and attach a profiler to examine the application behaviour.

David Rabinowitz
+1  A: 

There is no "best" option (if there was, anyone would use it, right?) but maybe an option which helps in your case. But here are some tips:

  • Use the latest VM. The GC code got better with every release.
  • Use the client jvm.dll (available sinve Java 1.5 in jre/bin/client/). This should be the default.
  • Allocating and freeing objects in Java is cheap. It's expensive to keep them around.
Aaron Digulla
Are you actually saying that you think keeping a pool of objects is worse than constantly creating objects and forcing the GC to clean them up?
tloach
That is correct in most circumstances.
Stephen C
@tloach: Yes. Objects which can't be reached anymore (= there are no references which point to them) cost nothing during the GC.
Aaron Digulla
A: 

If you want better performance then give the garbage collector less work. Consider using a pool of objects rather than constantly creating and dumping them, and make sure you need every object you create.

tloach
+2  A: 

There is no single answer to this question, it is highly depending on what your application is doing and how it manages its objects. Maybe have a look at How does garbage collection work and Parallel and concurrent garbage collectors to understand the various options.

Then, check the Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning document that expands on GC tuning concepts and techniques for Java SE 6 that were introduced in the Tuning Garbage Collection with the 5.0 Java Virtual Machine document.

If you want to keep garbage collection pauses short, the concurrent collector is likely the right direction as it performs most of its work concurrently (i.e., while the application is still running). But finding the best setup will require profiling (consider measuring the GC throughput, the max and average pause time, the frequency of full GCs and their duration too).

(EDIT: Having read a comment from the OP, I think that reading My advice on JVM heap tuning, keep your fingers off the knobs! from the performance guru Kirk Pepperdine would be a good idea.)

Pascal Thivent
Thanks for the answer, but what would you look for in profiling. That is what data would indicate one direction over another?
Yishai
Well, usually, the GC throughput, the max and average pause time, frequency of full GC and their duration too (to find the best compromise). But it's hard to answer that for you :)
Pascal Thivent