Sun Microsystems Logo
First Previous Next Last Overview
 

LAB-1205: Java Application Performance Analysis

Exercise 9: Avoid explicit GC's (and get compilation information)

Learning goals of this exercise

In this exercise you will learn:

Background for this exercise

Please see Exercise 1 for an overview of running the javaperf GUI launcher.

As described in the Java Performance FAQ, calling system.gc() is a bad idea because the JVM often does a much better job at determining when to collect garbage at run time than a programmer at development time.  By using the command line option -XX:+DisableExplicitGC users can disable the effect of any system.gc() calls in the application.... which often leads to better performance.

Steps to follow

  1. For this exercise we use the same settings as in Exercise 8 (perm gen 12 MB, max heap 16 MB, new size 4 MB) but add the -XX:+DisableExplicitGC option.  We also demonstrate an additional option to get information on compiled methods, -XX:+PrintCompilation. We are also explicitly choosing the client compiler so that we can contrast the performance to that of the server compiler in the next exercise.
    compiler=-client
    heap=-XX:PermSize=12m -XX:MaxPermSize=12m -XX:NewSize=4m -XX:MaxNewSize=4m -Xms16m -Xmx16m
    gc=-XX:+DisableExplicitGC
    other=-XX:+PrintCompilation

  2. Click [Start]. You will see the Java 2D Demo application start....  Immediately click on the "Transforms" tab. Then click into the "Shear" area so it fills the entire window.

  3. Notice are no full collections any more!  The 3 (or 4) full collections we are used to have disappeared (because they were explicit system.gc() calls).

  4. When you see that the application runtime goes just over one minute click [Stop]

  5. By eliminating the explicit GC's we have cut down 75% of our time in GC -- now only 0.5%!  We also have some more information about compilation.
    [Exercise09-Java2DemoLog]

Summary

When should you disable explicit GC's?  Disabling explict GC's is nearly always a good idea...  The best way to know for sure is to test your application with and without this option.  One case where you want explicit GC's is when using RMI.  As described in the Other Considerations sections of the Tuning Garbage Collection with the 5.0 Java™ Virtual Machine document, RMI may need explicit GC's to free some remote objects.  Note that the frequency of distributed garbage collection with RMI is also tunable (as described in the document).

What can we learn about compilation?  Here, by default, we are using the client compiler.  This compiler is very quick at compiling methods (but may not make fully optimal compilations).  You can get a rough idea of the number of compilations by counting the lines in the log file (for this example we had 922 compiles).

Next Steps