If you're using RMI in your application, your JVM is likely to perform too many unnecessary full GC's.
This causes your application to freeze for too long and may cause for serious performance problems.

Why is that?
By default, RMI calls System.gc() once every minute. this forces a major collection (full GC) to occur.
a full GC is a collection of type "Stop The World", which means the JVM freezes until the GC is over.

Note that telling the JVM to perform a full GC every minute isn't needed, since your JVM knows by itself when to perform a full GC.
But not only it isn't needed, it also causes your application to freeze for an amount of time ranging from several ms. to a full second
(depending on your heap settings and application load).

In order to avoid unnecessary freezes in your application, you have two options:

1) Disable completely the option to call System.gc() from the code, by using the following JVM parameter:
-XX:+DisableExplicitGC

2) Set the RMI garbage collection intervals (in this example, the RMI collection will occur once an hour):
-Dsun.rmi.dgc.client.gcInteraval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

To conclude: by default, if you're using RMI on Sun JVM, the JVM performs a full GC once a minute.
This can cause performance problem due to the freezes caused by the full GC.
In order to avoid that, you can either disable explicit calls to System.gc(), or tune the RMI GC to perform in a predefined interval.
 

 

1

Comments

You may of course use: -XX:MaxGCPauseMillis= "A hint to the virtual machine that pause times of nnn milliseconds or less are desired. The VM will adjust the java heap size and other GC-related parameters in an attempt to keep GC-induced pauses shorter than nnn milliseconds. Note that this may cause the VM to reduce overall throughput, and in some cases the VM will not be able to meet the desired pause time goal. By default there is no pause time goal. There are definite limitations on how well a pause time goal can be met. The pause time for a GC depends on the amount of live data in the heap. The minor and major collections depend in different ways on the amount of live data. This parameter should be used with caution. A value that is too small will cause the system to spend an excessive amount of time doing garbage collection." and see also: JVM tuning at Gigaspaces: http://forum.openspaces.org/thread.jspa?messageID=9277 An old post about tuning: http://www.tikalk.com/java/performance-tunning-case-study