Quelqu'un peut -il expliquer ce que s'il vous plaît l'option JVM ReservedCodeCacheSizeet InitialCodeCacheSizesont? Plus précisément, quand / pourquoi voudrais-je le changer? Comment décider quelle est la bonne taille?
Voici ce que disent les documents:
-XX: ReservedCodeCacheSize = 32m Taille du cache de code réservé (en octets) - taille maximale du cache de code. [Solaris 64 bits, amd64 et -server x86: 2048m; dans 1.5.0_06 et versions antérieures, Solaris 64 bits et and64: 1024m.]
Réponses:
ReservedCodeCacheSize(et InitialCodeCacheSize) est une option pour le compilateur (juste à temps) de la VM Java Hotspot. Fondamentalement, il définit la taille maximale du cache de code du compilateur.
Le cache peut devenir plein, ce qui entraîne des avertissements tels que:
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
C'est bien pire lorsqu'il est suivi par Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.
Quand définir cette option?
Normalement, vous ne modifiez pas cette valeur. Je pense que les valeurs par défaut sont assez bien équilibrées car ces problèmes ne surviennent qu'en de très rares occasions (d'après mon expérience).
Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and amd64: 1024m.]ne connaît pas les valeurs OpenJDK. Une augmentation modérée devrait être suffisante (un réglage antérieur de 1024 m était au-delà du bien et du mal).
@jeha répond à tout ce que je voulais savoir de cette question, à part sur quelle valeur définir les paramètres. Comme je n'ai pas écrit le code que je déployais, je n'avais pas beaucoup de visibilité sur l'empreinte mémoire qu'il avait.
Cependant, vous pouvez utiliser jconsole pour vous attacher à votre processus java en cours d'exécution, puis utiliser l'onglet «Mémoire» pour connaître la taille du cache de code. Pour être complet, les étapes sont (environnement de machine virtuelle Linux, même si je suis sûr que d'autres environnements sont similaires):
Encore une fois, cela peut prendre quelques instants pour que l'écran se rafraîchisse, puis vous devriez voir quelque chose comme:
Comme vous pouvez le voir, mon cache de code utilise environ 49 Mo. À ce stade, j'avais toujours la valeur par défaut qui, selon la documentation (et @jeha), est de 48 Mo. Certainement une grande motivation pour moi d'augmenter le réglage!
Ben.
1024 Mo par défaut en faisaient probablement trop, mais 48 Mo par défaut semblent en faire trop ...
Une bonne expérience d'apprentissage de la part de l'équipe d'ingénieurs Indeed et les défis auxquels ils ont été confrontés lors de la migration vers jdk 8.
http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/
Conclusion: Jdk 8 a besoin de plus de cache de code que JDK 7
La taille par défaut du cache de codecache pour JRE 8 est d'environ 250 Mo, environ cinq fois plus que la valeur par défaut de 48 Mo pour JRE 7. D'après notre expérience, JRE 8 a besoin de ce cache de codec supplémentaire. Jusqu'à présent, nous avons basculé une dizaine de services vers JRE 8, et tous utilisent environ quatre fois plus de cache de code qu'auparavant.
depuis https://blogs.oracle.com/poonam/entry/why_do_i_get_message :
Voici deux problèmes connus dans jdk7u4 + en ce qui concerne le vidage CodeCache:
- Le compilateur peut ne pas être redémarré même après que l'occupation de CodeCache tombe à presque la moitié après le vidage d'urgence.
- Le vidage d'urgence peut entraîner une utilisation élevée du processeur par les threads du compilateur, entraînant une dégradation des performances globales.
Ce problème de performances et le problème de la réactivation du compilateur ont été résolus dans JDK8. Pour contourner ces problèmes dans JDK7u4 +, nous pouvons augmenter la taille du cache de code à l'aide de l'option ReservedCodeCacheSize en la définissant sur une valeur supérieure à l'encombrement du code compilé afin que CodeCache ne devienne jamais plein. Une autre solution consiste à désactiver CodeCache Flushing à l'aide de l'option JVM -XX: -UseCodeCacheFlushing.
Les problèmes mentionnés ci-dessus ont été corrigés dans JDK8 et ses mises à jour.
Ces informations méritent donc d'être mentionnées pour les systèmes fonctionnant sous JDK 6 (dont le rinçage du code est désactivé) et 7.