How to tune a jvm to crash instead of heroically GC till 100% CPU utilization?

Question

We have a JVM process that infrequently pegs the CPU at 100%, with what appears to be (according to visualgc) a very nearly exhausted heap. Our supposition is that the process is heroically GC'ing causing a CPU spike, which is affecting the overall health of the entire system (consisting of other JVMs doing different things).

This process is not critical and can be restarted. Is there a way to tune the JVM via the command line which starts it to make it fall on its own sword rather than it keep GC'ing and causing the entire box to suffer?

Of note is that we are not getting OOMExceptions, so the heap isn't TOTALLY exhausted, but just barely not, we think.

Alternatively, something to give us some insight as to what in the JVM is actually using the CPU in the way that it is to confirm/deny our GC supposition?

Answer 1

The parallel and concurrent collectors have an "overhead limit" that might do what you want:

if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown

See http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html for more information.

Answer 2

We can get the statistics from

1):The option -XX:+PrintGCTimeStamps will add a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.

With the above option we can get rough estimation whether you supposition that the process is heroically GC'ing causing a CPU spike or not .

If your suppossition is right then start tunig your GC .

 Both parallel collector and Concurrent Collector will throw an OutOfMemoryError if too much time is being
 spent in garbage collection: if more than 98% of the total time is spent in garbage collection and 
less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. the option X:-UseGCOverheadLimit 
 is enabled by default for both Parallel and concurrent collector . Check whether this option is disabled in
 your system .  

For more information about Gc tuning in JVM refer this and for vm debugging options check this

Answer 3

The best thing to do is to find out the memory leak and fix it.

A simple way to exit on high memory usage:

if(Runtime.getRuntime().totalMemory()>100*1024*1024)
    System.exit(0);