java - forzar - Se excedió el límite superior del GC

garbage collector tomcat (1)

¿Cuál es el tiempo de muestreo que utiliza JVM para arrojar ''java.lang.OutOfMemoryError: el límite superior del GC excedido''? Sé que puedes controlar el 98% y el 2% con los parámetros GCTimeLimit y GCHeapFreeLimit, pero ¿cuál es el tiempo de muestreo?

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

el seguimiento

Tiempo GC excesivo y OutOfMemoryError
El recopilador simultáneo arrojará un OutOfMemoryError si se gasta demasiado tiempo en la recolección de elementos no utilizados: si se gasta más del 98% del tiempo total en recolección de basura y se recupera menos del 2% del montón, se lanzará OutOfMemoryError. Esta función está diseñada para evitar que las aplicaciones se ejecuten durante un período de tiempo prolongado sin apenas progreso porque el montón es demasiado pequeño. Si es necesario, esta función se puede desactivar agregando la opción -XX: -UseGCOverheadLimit a la línea de comando.
La política es la misma que en el recopilador paralelo, excepto que el tiempo dedicado a realizar colecciones concurrentes no se cuenta hacia el límite de tiempo del 98%. En otras palabras, solo las recolecciones realizadas mientras la aplicación está detenida cuentan para un tiempo GC excesivo. Dichas colecciones se deben normalmente a un error de modo concurrente o una solicitud de recopilación explícita (por ejemplo, una llamada a System.gc ()).

junto con un pasaje más abajo

Uno de los usos más comunes de la recolección explícita de basura ocurre con la recolección de basura distribuida (DGC) de los RMI. Las aplicaciones que usan RMI se refieren a objetos en otras máquinas virtuales. No se puede recolectar basura en estas aplicaciones distribuidas sin recolectar ocasionalmente el montón local, por lo que RMI fuerza recolecciones completas periódicamente. La frecuencia de estas colecciones se puede controlar con propiedades. Por ejemplo,
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 especifica la recopilación explícita una vez por hora en lugar de la tasa predeterminada de una vez por minuto. Sin embargo, esto también puede causar que algunos objetos tarden mucho más en recuperarse. Estas propiedades se pueden establecer tan altas como Long.MAX_VALUE para hacer que el tiempo entre colecciones explícitas sea efectivamente infinito, si no se desea un límite superior en la puntualidad de la actividad DGC.

Parece implicar que el período de evaluación para determinar el 98% es de un minuto de duración, pero puede ser configurable en la JVM de Sun con la definición correcta.

Por supuesto, otras interpretaciones son posibles.