¿Qué causa una fuga de caché de código JRE 6 JVM?

Question

Desde que cambié a JRE 6, el uso de caché de código de mi servidor (sin almacenamiento dinámico) sigue creciendo indefinidamente. Mi aplicación crea muchas clases en tiempo de ejecución, PERO estas clases se descargan con éxito durante el proceso de GC. Veo que estas clases se descargan en los registros de gc y también el uso de permGen se mantiene constante. Específicamente me aseguro en mi código de que estas clases sean huérfanas una vez que haya terminado con ellas y que reciban correctamente la basura recolectada de permGen.

Sin embargo, el caché de código sigue creciendo. Solo me di cuenta de la caché del código después de cambiar a JRE 6. Así que supongo que mis preguntas son:

1. ¿Incluye GC el caché del código?
2. Lo que podría causar una fuga de memoria de caché de código, específicamente.
3. ¿Hay algún error en JDK 6 en esta área?

Answer 1

¿Es posible invocar jvisualvm (en el JDK) contra la aplicación problemática? Puede fácilmente hacerte mucho más sabio sobre lo que está sucediendo.

Answer 2

Es posible que desee mirar a través de esta discusión y sólo tiene que ir hacia atrás para ver lo que puede ser útil para tratar de reducir esta abajo: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-January/000530.html

Ésta implica JDK5 pero puede ser útil: http://www.nabble.com/Java-code-cache-memory-td22202283.html

¿Estás usando esto para compilar páginas jsp, o algo similar? Si no, ¿qué se compila después de que se inicia la aplicación? ¿Estás usando AspectJ con el tejido en tiempo de ejecución?

Ayudaría saber lo que está haciendo para tener una mejor idea de cómo ayudar.

Además, cuando el caché del código está agotado, ¿simplemente deja de compilar de nuevo o se bloquea el jvm? Yo esperaría lo primero.

¿Está utilizando Sun's JDK? Supongo que lo es porque dudo que los demás estén en la lista como versión 6, pero no está de más preguntar.

Answer 3

Me preguntaba si el nuevo G1 Garbage Collector (a partir de Java 6 actualización 14) podría ayudarlo. Puede intentarlo con -XX: + UnlockExperimentalVMOptions -XX: + UseG1GC, pero de acuerdo con comments on Jon Masamitsu's blog no lo hará (si el problema se debe realmente a la memoria caché del código). Pero tal vez la discusión allí o los enlaces de allí podrían ayudar.

Answer 4

A partir de los comentarios en esta entrada del blog: http://blogs.oracle.com/jonthecollector/entry/our_collectors

código es desalojado cuando se descargan las clases (como así, como cuando los métodos son "invalidado", es decir, algunos supuestos se hicieron durante su compilación que no aguantar más)

si yo fuera tú, correría una carga de trabajo, tomaría un montón de archivos y verificaría si todas las clases son de GCC que usted espera.

Answer 5

Dos posibles lugares en los que buscaría el problema: Pérdida de cargadores y Massive String.

Desde la descripción de su aplicación, es más probable que verifique si el GC está descargando clases viejas generadas.

No creo que jConsole tenga una forma de visualizar esto, pero si puede obtener una copia de YourKit, tiene una forma gráfica de detectar ambos problemas.

Answer 6

1. no, pero se puede usar -XX: + bandera UseCodeCacheFlushing dejar que la JVM disponer una parte del código compilado cuando la caché de código se llena, aunque no es tan útil a veces. intente -XX: ReservedCodeCacheSize y -XX: CompileThreshold.
2. despliegues calientes de vez en cuando, etc.

ver más: https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-4-heap-tuning/