usegcoverheadlimit java jvm jvm-hotspot jvm-arguments

usegcoverheadlimit - Sintonización de Java VM-Xbatch y-Xcomp



java jvm options (2)

Alfresco es una gestión de contenido empresarial. No estoy seguro de cómo las banderas afectan su rendimiento. Luego, una nota en la misma página decía ...

- Sin embargo, esto aumentará significativamente el tiempo de inicio del servidor, pero resaltará las dependencias faltantes que pueden alcanzarse más tarde. ...

En mi humilde opinión, el autor realmente no quiso decir una ganancia de rendimiento. Lo escribió como un medio para verificar que todas las dependencias están en su lugar.

Estoy analizando las opciones de configuración de JVM para ejecutar Alfresco, principalmente this documento en el Wiki de Alfresco . Una de las recomendaciones es utilizar los indicadores JVM -Xcomp y -Xbatch . La justificación de esto es:

Si desea que Hotspot precompile las clases, puede agregar [-Xcomp y -Xbatch]. Sin embargo, esto aumentará significativamente el tiempo de inicio del servidor, pero resaltará las dependencias faltantes que pueden alcanzarse más tarde.

Por lo que he leído en otros lugares sobre las banderas -Xcomp y -Xbatch , me pregunto si realmente proporcionan algún beneficio.

  • -Xcomp hace que HotSpot compile todo el código de antemano con la optimización máxima, por lo que se descarta cualquier perfil que la VM obtenga a través del funcionamiento estándar del sistema.
  • -Xbatch detiene la compilación en segundo plano, es decir, el subproceso que hizo que el código se compilara hasta que se completara la compilación. Sin embargo, una vez finalizada la compilación, el subproceso previamente bloqueado no ejecutará el código compilado , aún ejecutará el código interpretado . Esto fue un cambio en Java 6 (Mustang): antes de Mustang, se garantizaba que los subprocesos bloqueados para compilar por la presencia del -Xbatch se ejecutarían en el código compilado tan pronto como se completara la compilación. Por lo tanto, supongo que la recomendación del indicador -Xbatch es una reliquia de ejecutar Alfresco en máquinas virtuales más antiguas.

Alguien tiene alguna opinión? Mi inclinación es deshacerme de estas dos banderas y confiar en la VM para hacer las cosas bien.

Me gustaría agregar dos cosas, en primer lugar, que aún no tengo acceso a una instancia de Alfresco para probar esto y, en segundo lugar, no sé realmente qué especificaciones de la máquina hospeda Alfresco, aparte de eso al mirar al otro opciones de configuración debe ser una máquina virtual de 64 bits. A pesar de esto, espero que la comunidad tenga algún aporte útil, tal vez desde un punto de vista general de ajuste de HotSpot.


En general, siempre es preferible dejar que el compilador HotSpot se sintonice. Incluso el uso de Server VM (-server) es predeterminado para 64 bits y algunas máquinas de "clase de servidor".

-Xbatch fue pensado principalmente para la depuración como se describe en el blog de Steve Goldman que usted señaló:

Por lo tanto, el interruptor -Xbatch no es un interruptor particularmente útil incluso en los días previos al mustang. Es algo útil para los desarrolladores de jvm, ya que tiende a hacer que una ejecución sea más predecible y reproducible.

-Xcomp elimina la capacidad de recopilar información para una compilación eficiente. De la publicación de Alex Turner :

Uno podría pensar que -Xcomp sería una buena idea desde el punto de vista del rendimiento. Sin embargo, no lo es! El compilador JIT usa esas 1000 iteraciones antes de la compilación para recopilar información sobre cómo se debe compilar el método para una eficiencia óptima. -Xcomp elimina su capacidad para hacerlo y, por lo tanto, podemos ver una caída en el rendimiento.

Sin el rendimiento en mente, nunca he visto el uso de esos indicadores para detectar dependencias faltantes ( y puede que no funcione si aún se interpreta algún código ), así que en mi humilde opinión, me desharía de ambos.