Question Qu'est-ce que ReservedCodeCacheSize et InitialCodeCacheSize?


Quelqu'un peut-il s'il vous plaît expliquer ce que l'option de la JVM ReservedCodeCacheSize et InitialCodeCacheSize sont? Spécifiquement quand / pourquoi voudrais-je le changer? Comment est-ce que je décide quelle est la bonne taille?

Voici ce que disent les médecins:

-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: 2048 m; dans 1.5.0_06 et versions antérieures, Solaris 64 bits et 64: 1024 m.]


74
2017-09-22 10:17


origine


Réponses:


ReservedCodeCacheSize (et InitialCodeCacheSize) est une option pour le compilateur (juste à temps) de la machine virtuelle 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 comme ceux-ci:

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

Il est bien pire quand 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?

  1. en cas d'échec du compilateur Hotspot
  2. réduire la mémoire nécessaire à la JVM (et donc risquer des échecs du compilateur JIT)

Normalement, vous ne modifiez pas cette valeur. Je pense que les valeurs par défaut sont assez bien équilibrées car cela ne se produit que dans de très rares occasions (dans mon expérience).


66
2017-09-22 19:22



@jeha répond à tout ce que je voulais savoir à partir de cette question, en dehors de la valeur à laquelle définir les paramètres. Comme je n’avais pas écrit le code que je déployais, je n’avais pas beaucoup de visibilité sur l’encombrement de la mémoire.

Cependant, vous pouvez utiliser jconsole pour 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 Linux VM, même si je suis sûr que d’autres environnements sont similaires):

  1. Jconsole jconsole sur votre machine
  2. Trouvez le bon identifiant de processus et joignez-y jconsole (cela prendra quelques instants)
  3. Accédez à l'onglet "Mémoire".
  4. Dans la liste déroulante "Graphique:", sélectionnez "Cache de mémoire" Cache de code ""
  5. Encore une fois, cela peut prendre quelques instants pour que l'écran se régénère, puis vous devriez voir quelque chose comme: jconsole code cache image

    Comme vous pouvez le voir, mon cache de code utilise environ 49 Mo. À ce stade, j'avais toujours la valeur par défaut indiquée par la documentation (et @jeha): 48 Mo. Certainement une grande motivation pour que j'augmente le cadre!

    Ben.


    1024 Mo par défaut était probablement exagéré, mais 48 Mo par défaut semble le sous-estimer ...


12
2018-06-03 11:37



Lorsque la JVM compile du code, il contient l’ensemble des instructions en langage assembleur cache de code. Le cache de code a une taille fixe et, une fois rempli, la JVM n’est plus capable de compiler tout code supplémentaire.

La taille maximale du cache de code est définie via l'indicateur -XX: ReservedCodeCacheSize = N (où N est la valeur par défaut mentionnée pour le compilateur particulier). Le cache de code est géré comme la plupart des mémoires dans la JVM: il y a une taille initiale ( -XX: InitialCodeCacheSize = N). L'attribution de la taille du cache de code commence à l'initialisation taille et augmente à mesure que le cache se remplit. La taille initiale du cache de code varie en fonction de l'architecture de la puce et le compilateur en cours d'utilisation. Redimensionner le le cache se produit en arrière-plan et n'affecte pas vraiment les performances, La taille ReservedCodeCacheSize (c.-à-d. La définition de la taille maximale du cache de code) est tout ce qui est généralement nécessaire.

Par défaut, pour un serveur 64 bits, la taille de Java 7 est de 48 Mo (avec une compilation en plusieurs niveaux de 96 Mo). En Java 8 pour le serveur 64 bits, la taille de la mémoire est de 240 Mo.

- Pinaki


11
2017-10-10 20:48



Une bonne expérience d'apprentissage de l'équipe d'ingénieurs 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 nécessite plus de cache de code que JDK 7

La taille de codecache par défaut pour JRE 8 est d'environ 250 Mo, soit environ cinq fois plus que la valeur par défaut de 48 Mo pour JRE 7. Notre expérience est que JRE 8 a besoin de ce codecache supplémentaire. Jusqu'à présent, nous avons basculé une dizaine de services vers JRE 8 et tous utilisent environ quatre fois plus de codecache qu'auparavant.


1
2017-09-15 15:36



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

Voici deux problèmes connus dans jdk7u4 + concernant le vidage de CodeCache:

  1. Il se peut que le compilateur ne soit pas redémarré même après que l'occupation de CodeCache ait été presque réduite de moitié après le vidage d'urgence.
  2. Le vidage d'urgence peut entraîner une utilisation élevée du processeur par les threads du compilateur, entraînant une dégradation globale des performances.

Ce problème de performances et le problème de la non réactivation du compilateur ont été résolus dans JDK8. Pour les contourner dans JDK7u4 +, nous pouvons augmenter la taille du cache de code à l'aide de l'option ReservedCodeCacheSize en lui attribuant une valeur supérieure à celle du code compilé, afin que CodeCache ne soit jamais saturé. Une autre solution consiste à désactiver le rinçage de CodeCache en utilisant l'option JVM -XX: -UseCodeCacheFlushing.

Les problèmes mentionnés ci-dessus ont été corrigés dans JDK8 et ses mises à jour.

Donc, ces informations méritent d’être mentionnées pour les systèmes fonctionnant sur JDK 6 (avec le nettoyage de code désactivé) et 7.


0
2017-10-04 17:51