Se superó el límite de gastos generales de GC

¿Cuál es el tiempo de muestreo que utiliza JVM para generar 'java.lang.OutOfMemoryError: GC overhead limit excedido'? Sé que puede 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] Ajuste de recolección de basura de máquina virtual

el seguimiento

Tiempo de GC excesivo y OutOfMemoryError

El recolector concurrente lanzará un OutOfMemoryError si se gasta demasiado tiempo en la recolección de basura: si más del 98% del tiempo total se dedica a la recolección de basura y se recupera menos del 2% del montón, se lanzará un OutOfMemoryError. Esta característica está diseñada para evitar que las aplicaciones se ejecuten durante un período prolongado de tiempo mientras avanzan poco o ningún 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 la del recopilador paralelo, excepto que el tiempo dedicado a realizar recopilaciones simultáneas no se cuenta para el límite de tiempo del 98%. En otras palabras, solo las recolecciones realizadas mientras la aplicación está detenida cuentan para el tiempo de GC excesivo. Tales colecciones se deben típicamente a un fallo de modo concurrente o una solicitud de colecció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 de basura explícita ocurre con la recolección de basura distribuida (DGC) de RMI. Las aplicaciones que utilizan RMI hacen referencia a objetos en otras máquinas virtuales. La basura no se puede recolectar 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 hacer 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 de DGC.

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

Por supuesto, son posibles otras interpretaciones.