Was sind ReservedCodeCacheSize und InitialCodeCacheSize?

Kann mir bitte jemand erklären, was die JVM-option ReservedCodeCacheSize und InitialCodeCacheSize sind? Speziell, wenn/warum will ich es ändern? Wie kann ich entscheiden, was die richtige Größe ist?

Dies ist, was die docs sagen:

-XX:ReservedCodeCacheSize=32m Reserviert code-cache-Größe (in Byte) - maximum-code-cache-Größe. [Solaris 64-bit, amd64 und x86-server: 2048m; in 1.5.0_06 und früher, Solaris 64-bit und and64: 1024m.]

InformationsquelleAutor der Frage Raghu | 2011-09-22

66

ReservedCodeCacheSize (und InitialCodeCacheSize) ist eine option für die (just-in-time) compiler, der Java Hotspot VM. Grundsätzlich legt die maximale Größe für den compiler, code-cache.

Kann der cache voll ist, werden die Ergebnisse in Warnungen wie die folgenden:
```
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 ist viel schlimmer, wenn gefolgt von Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

Wenn diese option?
1. wenn mit Hotspot compiler-Fehler
2. zu reduzieren benötigten Speichers durch die JVM (und damit zu riskieren, JIT-compiler-Fehler)
Normalerweise würde man diesen Wert nicht ändern. Ich denke, dass die default-Werte sind Recht gut ausgeglichen, da diese Probleme auftreten, in sehr seltenen Fällen nur (in meiner Erfahrung).

InformationsquelleAutor der Antwort jeha
12

@jeha Antworten alles, was ich wissen wollte aus dieser Frage, abgesehen von dem, was Wert, um die Parameter einzustellen. Da ich nicht den code schreiben, war ich bereitstellen, ich habe nicht viel Einblick in den Arbeitsspeicher hatte.

Allerdings können Sie mithilfe der jconsole zu befestigen, um Ihre Laufenden java-Prozess, und verwenden Sie dann den "Memory" - Registerkarte, um herauszufinden, den Code-Cache-Größe. Der Vollständigkeit halber werden die Schritte (Linux VM-Umgebung, aber ich bin sicher, dass andere Umgebungen sind ähnlich):
1. Feuer bis jconsole auf Ihrem Computer
2. Finden Sie die richtige Prozess-ID und befestigen Sie jconsole (dies dauert ein paar Momente)
3. Navigieren Sie zu dem "Memory" - Registerkarte
4. Von der 'Chart:" drop-down-Liste wählen Sie 'Memory Pool "Code-Cache"'
5. Wieder, dies kann einen Moment dauern, den Bildschirm zu aktualisieren, und Sie sollten etwas sehen wie:
  
  Wie Sie sehen können, mein code cache ist ca 49 MB. Zu diesem Zeitpunkt hatte ich noch den Standard der Dokumentation (und @jeha) sagt, ist 48 MB. Sicherlich eine große motivation für mich zu erhöhen Sie die Einstellung!
  
  Ben.
  
  1024 MB standardmäßig war wohl übertrieben, aber 48 MB zu sein scheint, underdoing...
InformationsquelleAutor der Antwort Animal451
11

Wenn die JVM kompiliert den code, es gilt der Satz von assembly-Anweisungen in der Sprache
code-cache. Der code-cache hat eine Feste Größe, und sobald es aufgefüllt hat, ist die JVM nicht
kompilieren können alle zusätzlichen code.

Die maximale Größe des code-cache wird über den-XX:ReservedCodeCacheSize=N-flag
(wo N ist die Standardeinstellung, nur die erwähnten, für den jeweiligen compiler). Der code-cache
verwaltet wie die meisten Speicher in der JVM: es gibt eine erste Größe (
-XX:InitialCodeCacheSize=N). Zuordnung der code-cache-Größe beginnt bei der ersten
Größe und erhöht sich, wenn der cache voll ist. Die ursprüngliche Größe des code-cache variiert je nach
die chip-Architektur und compiler im Einsatz. Die Größe des
cache im hintergrund geschieht und nicht wirklich auf die Leistung auswirken, sodass die Einstellung der
ReservedCodeCacheSize Größe (D. H., die Einstellung, die die maximale code-cache-Größe), das ist alles
in der Regel benötigt.

Standardmäßig für 64-bit-server, Java 7-Größe 48 MB (mit abgestuften Zusammenstellung seiner 96 MB). In Java 8 für 64-bit-server-Speicher Größe ist 240 MB.

-- Pinaki

InformationsquelleAutor der Antwort Pinaki Mukherjee
1

Eine gute Erfahrung von in der Tat engineering-team und die Herausforderungen, die Sie konfrontiert, wenn Sie auf jdk 8.

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

Fazit : Jdk 8 braucht mehr code cache han JDK 7

Den Standard-codecache Größe für JRE 8 ist über 250MB, etwa fünf mal größer als 48 MB Standard für JRE 7. Unsere Erfahrung ist, dass die JRE 8 braucht die extra-codecache. Wir geschaltet haben, über zehn Dienstleistungen JRE 8 so weit, und alle von Ihnen Einsatz rund vier mal mehr codecache als vorher.

InformationsquelleAutor der Antwort vsingh
0

vom https://blogs.oracle.com/poonam/entry/why_do_i_get_message:
Im folgenden werden zwei bekannte Probleme in jdk7u4+ mit Bezug auf den CodeCache Spülung:
1. Der compiler kann nicht neu gestartet wurde, auch nach der CodeCache Belegung lässt sich blitzartig fallen fast die Hälfte nach der not-Spülung.
2. Der Notfall-Spülung verursachen hohe CPU-Auslastung durch die compiler-threads führt zu Allgemeinen Leistungsabfall.
Diesem performance-Problem, und das problem des Compilers, nicht immer wieder erneut aktiviert wurde angesprochen im JDK8. Zur Umgehung dieser in JDK7u4+, erhöhen wir den code-cache-Größe mit ReservedCodeCacheSize option mit der Einstellung ein Wert größer als der compiled-code-footprint, so dass der CodeCache nie voll wird. Eine andere Lösung ist das deaktivieren der CodeCache Spülung mit -XX:-UseCodeCacheFlushing JVM-option.

Die oben genannten Probleme wurden behoben, bei JDK8 und seine updates.
So, dass die Informationen vielleicht zu erwähnen, für Systeme laufen auf JDK 6 (mit code Spülung deaktiviert) und 7.

InformationsquelleAutor der Antwort Andre Steingress

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.