GC overhead limit exceeded

by

From Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

the following

Excessive GC Time and OutOfMemoryError

The 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. This feature
is designed to prevent applications from running for an extended
period of time while making little or no progress because the heap is
too small. If necessary, this feature can be disabled by adding the
option
-XX:-UseGCOverheadLimit to the command line.

The policy is the same as that in the parallel collector, except that
time spent performing concurrent collections is not counted toward the
98% time limit. In other words, only collections performed while the
application is stopped count toward excessive GC time. Such
collections are typically due to a concurrent mode failure or an
explicit collection request (e.g., a call to System.gc()).

in conjunction with a passage further down

One of the most commonly encountered uses of explicit garbage
collection occurs with RMIs distributed garbage collection (DGC).
Applications using RMI refer to objects in other virtual machines.
Garbage cannot be collected in these distributed applications without
occasionally collection the local heap, so RMI forces full collections
periodically. The frequency of these collections can be controlled
with properties. For example,

java -Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.dgc.server.gcInterval=3600000 specifies explicit collection once per hour instead of the default rate of once per
minute. However, this may also cause some objects to take much longer
to be reclaimed. These properties can be set as high as Long.MAX_VALUE
to make the time between explicit collections effectively infinite, if
there is no desire for an upper bound on the timeliness of DGC
activity.

Seems to imply that the evaluation period for determining the 98% is one minute long, but it might be configurable on Sun’s JVM with the correct define.

Of course, other interpretations are possible.

More Related Contents:

  1. How ‘random’ is allocation of memory when I say “new Integer” in Java?
  2. Java heap terminology: young, old and permanent generations?
  3. Analyzing gc logs
  4. Size of Huge Objects directly allocated to Old Generation
  5. Why does the JVM require warmup?
  6. Garbage collection on intern’d strings, String Pool, and perm-space
  7. How to calculate HashMap memory usage in Java?
  8. Is the garbage collector guaranteed to run before Out of Memory Error?
  9. Measuring time spent on GC
  10. How can I tell if I’m running in 64-bit JVM or 32-bit JVM (from within a program)?
  11. How to see JIT-compiled code in JVM?
  12. What is the exact meaning of static fields in Java?
  13. Running jmap getting Unable to open socket file
  14. Jvm takes a long time to resolve ip-address for localhost
  15. What is in Java object header?
  16. How do I find out what keystore my JVM is using?
  17. Garbage collection on a local variable
  18. Error launching Android Studio: Failed to create JVM: error code-6
  19. try with resources introduce unreachable bytecode
  20. When will JVM use intrinsics
  21. When and how are classes garbage collected in Java?
  22. Java still uses system memory after deallocation of objects and garbage collection
  23. Java VM: reproducible SIGSEGV on both 1.6.0_17 and 1.6.0_18, how to report?
  24. Will .hashcode() return a different int due to compaction of tenure space?
  25. How to set timezone to UTC in Apache Spark?
  26. What is the default maximum heap size for Sun’s JVM from Java SE 6?
  27. Why is there no GIL in the Java Virtual Machine? Why does Python need one so bad?
  28. How do you Force Garbage Collection from the Shell?
  29. Is it possible to use sun.misc.Unsafe to call C functions without JNI?
  30. Is *this* really the best way to start a second JVM from Java code?

Leave a Comment