¿Cuáles son las mejores configuraciones de recolección de basura para el lado del cliente?

Question

Las JVM recientes tienen muchos parámetros XX para la recolección de basura (ver here por ejemplo), pero ¿cuáles son las opciones que pueden hacer que una aplicación Swing del lado del cliente realmente tenga un mejor rendimiento?

Debo señalar que una de las cosas que realmente me molesta en las aplicaciones java del lado del cliente es la gran demora en la recolección de basura mundial. En Intelli-J IDEA lo he visto durar tres minutos o más.

EDIT: Gracias por todas las respuestas. Solo para informar, coloqué el recolector de basura de CMS para IDEA (que es una buena referencia común del tipo de aplicación con la que todos los que están leyendo esta pregunta están familiarizados) utilizando la configuración sugerida por here. También configuro -XX: + StringCache para ver si reduce los requisitos de memoria.

En general, la observación es que el rendimiento de funcionamiento regular no se degrada hasta el punto en que se puede observar mirándolo. La reducción de memoria es enorme usando la opción Caché de cadena; sin embargo, el método CMS no es exhaustivo y termina requiriendo detener el ciclo mundial de recolección de basura (de vuelta a la espera de tres minutos) para borrar la memoria (400MB en una ejecución) .

Sin embargo, dado el espacio reducido de la memoria, es posible que pueda poner una cantidad máxima de memoria más pequeña que evitará que las colecciones del mundo tengan tamaños más pequeños.

IDEA 8.1.4 viene con JDK 1.6.0_12, por lo que no he probado G1 todavía. Además, mi máquina solo tiene 2 núcleos, por lo que un enfoque G1 no se maximizará realmente. Es hora de golpear al jefe para obtener una máquina mejor;).

Answer 1

No hay una sola respuesta a esta pregunta, depende en gran medida de lo que hace su aplicación y cómo gestiona sus objetos. Tal vez echar un vistazo a How does garbage collection work y Parallel and concurrent garbage collectors para comprender las diversas opciones.

Luego, consulte el documento Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning que amplía los conceptos y técnicas de sintonización de GC para Java SE 6 que se introdujeron en el documento Tuning Garbage Collection with the 5.0 Java Virtual Machine.

Si desea mantener cortas las pausas de recolección de basura, es probable que el recopilador simultáneo sea la dirección correcta ya que realiza la mayor parte de su trabajo al mismo tiempo (es decir, mientras la aplicación aún se está ejecutando). Pero encontrar la mejor configuración requerirá un perfil (considere medir el rendimiento del GC, el tiempo de pausa máximo y promedio, la frecuencia de los GC completos y su duración también).

(EDIT: Después de leer un comentario de la OP, creo que la lectura My advice on JVM heap tuning, keep your fingers off the knobs! del gurú rendimiento Kirk Pepperdine sería una buena idea.)

Answer 2

La sintonización de la recolección de basura es más que un arte, entonces la ciencia, y realmente depende de su aplicación y su uso. Si le molestan las estrategias estándar de detener el mundo, ¿por qué no convertir al CMS (marca concurrente y barrido) o al nuevo colector G1?

La mejor manera es cambiar los parámetros y adjuntar un generador de perfiles para examinar el comportamiento de la aplicación.

Answer 3

No existe la "mejor" opción (si la hubiera, alguien la usaría, ¿verdad?) Pero tal vez una opción que ayude en su caso. Pero aquí hay algunos consejos:

• Utilice la última máquina virtual. El código de GC mejoró con cada lanzamiento.
• Utilice el cliente jvm.dll (disponible sinve Java 1.5 en jre/bin/client/). Esto debería ser el predeterminado.
• La asignación y liberación de objetos en Java es barata. Es costoso mantenerlos cerca.

Answer 4

Si quiere un mejor rendimiento, entonces le da menos trabajo al recolector de basura. Considere usar un conjunto de objetos en lugar de crearlos constantemente y deshacerse de ellos, y asegúrese de que necesita todos los objetos que cree.

Answer 5

Esto es bastante automático y funciona para nosotros:

-server -Xss4096k -Xms12G -Xmx12G -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:GCTimeRatio=19 -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=500 -XX:+PrintGCTaskTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintTenuringDistribution -Xloggc:gc.log