ChatGPT解决这个技术问题 Extra ChatGPT

GC overhead limit exceeded

What is the sampling time JVM uses to throw 'java.lang.OutOfMemoryError : GC overhead limit exceeded'? I know you can control 98% and 2% with parameters GCTimeLimit and GCHeapFreeLimit but whats the sampling time?


J
Joachim Sauer

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.


RMI distributed garbage collection is an unrelated activity to regular garbage collection. So I don't see how you can infer what you just did.
The inference isn't perfect or even correct, that's why "seems to imply" is used instead of "implies". If you agree with the observation that if the folks over at Sun used one minute in determining the garbage collection interval for RMI, that collection time in concurrent collection is only accumulated calculated when the main program halts, and make a bit of a leap of faith, then odds are good the 98% is collected over one minute. It's a magic number, but one minute is a magic number often used in comparison to say 3.5 minutes.
@StephenC do you mean even if we set -XX:+DisableExplicitGC it will not impact RMI related configuration and system will invoke gc in frequency set with parameter -Dsun.rmi.dgc.server.gcInterval
@Steephen - No. That's not what I am saying. I'm talking about this statement: "Seems to imply that the evaluation period for determining the 98% is one minute long ...". And note that Edwin agrees that the inference is "imperfect". The inference is based on the assumption that that the Sun folks who implemented RMI (& DGC) were in close communication with the folks who implemented the GC overhead limit mechanism. I suspect that the two developments actually happened at different times. Note that the -Dsun.rmi.dgc.server.gcInterval property has been around since Java 1.2.
Anyway, a better approach to finding the real answer to this question would be to look at the OpenJDK source code.