java - ¿Qué son ReservedCodeCacheSize y InitialCodeCacheSize?

jvm jvm-hotspot

Question

¿Puede alguien explicar cuál es la opción de JVM ReservedCodeCacheSize y InitialCodeCacheSize ? Específicamente cuándo / por qué querría cambiarlo? ¿Cómo decido cuál es el tamaño correcto?

Esto es lo que dicen los documentos:

-XX: ReservedCodeCacheSize = 32m Tamaño de caché de código reservado (en bytes) - tamaño máximo de caché de código. [Solaris de 64 bits, amd64 y -server x86: 2048m; en 1.5.0_06 y anteriores, Solaris de 64 bits yy64: 1024m.]

Answer 1

@jeha responde todo lo que quería saber a partir de esta pregunta, aparte del valor para establecer los parámetros. Como no escribí el código que estaba implementando, no tenía mucha visibilidad de la huella de memoria que tenía.

Sin embargo, puede usar jconsole para adjuntarlo a su proceso java en ejecución, y luego usar la pestaña ''Memoria'' para averiguar el tamaño de la caché de código. Para completar, los pasos son (entorno Linux VM, aunque estoy seguro de que otros entornos son similares):

1. Encienda jconsole en su máquina
2. Encuentre la ID de proceso correcta y adjunte jconsole a ella (esto tomará unos minutos)
3. Ve a la pestaña ''Memoria''
4. En la lista desplegable ''Chart:'', seleccione ''Memory Pool'' Code Cache ''''

5. Nuevamente, esto puede tomar unos minutos para que la pantalla se actualice, y luego debería ver algo como:

   Como puede ver, mi código de caché utiliza aproximadamente 49 MB. En este punto todavía tenía el valor predeterminado que la documentación (y @jeha) dice que es de 48 MB. Sin duda una gran motivación para mí para aumentar el ajuste!

   Ben.

   1024 MB de forma predeterminada probablemente se estaba excediendo, pero 48 MB por defecto parece estar haciéndolo por debajo ...

Answer 2

Cuando la JVM compila el código, contiene el conjunto de instrucciones en lenguaje ensamblador en la memoria caché del código. El caché de código tiene un tamaño fijo, y una vez que se ha llenado, la JVM no puede compilar ningún código adicional.

El tamaño máximo de la memoria caché de código se establece a través del indicador -XX: ReservedCodeCacheSize = N (donde N es el valor predeterminado que se acaba de mencionar para el compilador en particular). El caché del código se administra como la mayoría de la memoria en la JVM: hay un tamaño inicial (-XX: InitialCodeCacheSize = N). La asignación del tamaño de la memoria caché de código comienza en el tamaño inicial y aumenta a medida que se llena el caché. El tamaño inicial de la memoria caché del código varía según la arquitectura del chip y el compilador en uso. Cambiar el tamaño del caché ocurre en segundo plano y realmente no afecta el rendimiento, por lo que todo lo que generalmente se necesita es establecer el tamaño del Tamaño de caché reservada (es decir, establecer el tamaño máximo de caché del código).

De forma predeterminada para el servidor de 64 bits, el tamaño de Java 7 es de 48 MB (con una compilación por niveles de 96 MB). En Java 8 para el servidor de 64 bits, el tamaño de la memoria es de 240 MB.

- Pinaki

Answer 3

Una buena experiencia de aprendizaje del equipo de ingeniería de Indeed y los desafíos que enfrentaron al migrar a jdk 8.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

Conclusión: Jdk 8 necesita más caché de código han JDK 7

El tamaño de caché de código predeterminado para JRE 8 es de aproximadamente 250 MB, aproximadamente cinco veces más grande que el valor predeterminado de 48 MB para JRE 7. Nuestra experiencia es que JRE 8 necesita ese código adicional. Hasta el momento hemos cambiado aproximadamente diez servicios a JRE 8, y todos ellos usan cuatro veces más codecache que antes.

Answer 4

de https://blogs.oracle.com/poonam/entry/why_do_i_get_message :

Los siguientes son dos problemas conocidos en jdk7u4 + con respecto a la descarga de CodeCache:

1. Es posible que el compilador no se reinicie incluso después de que la ocupación de CodeCache se reduzca a casi la mitad después del enjuague de emergencia.
2. El enjuague de emergencia puede causar un alto uso de la CPU por parte de los subprocesos del compilador, lo que conduce a una degradación general del rendimiento.

Este problema de rendimiento y el problema de que el compilador no se vuelva a habilitar de nuevo se ha abordado en JDK8. Para solucionar estos problemas en JDK7u4 +, podemos aumentar el tamaño de la memoria caché de código utilizando la opción ReservedCodeCacheSize, estableciéndola en un valor mayor que la huella del código compilado para que la CodeCache nunca se llene. Otra solución para esto es deshabilitar la descarga de CodeCache usando la opción de JVM -XX: -UseCodeCacheFlushing.

Los problemas mencionados anteriormente se han corregido en JDK8 y sus actualizaciones.

Por lo tanto, esa información podría valer la pena mencionar para los sistemas que se ejecutan en JDK 6 (que tiene el enjuague de código desactivado) y 7.

Answer 5

ReservedCodeCacheSize (y InitialCodeCacheSize ) es una opción para el compilador (justo a tiempo) de la máquina virtual Java Hotspot. Básicamente, establece el tamaño máximo para el caché de código del compilador.

La memoria caché puede llenarse, lo que genera advertencias como las siguientes:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

Es mucho peor cuando es seguida por la Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated .

Cuándo establecer esta opción?

1. al tener fallas en el compilador de Hotspot
2. para reducir la memoria que necesita la JVM (y por lo tanto arriesgar fallas en el compilador JIT)

Normalmente no cambiarías este valor. Creo que los valores predeterminados son bastante buenos porque estos problemas ocurren solo en muy raras ocasiones (en mi experiencia).