Was sind ReservedCodeCacheSize und InitialCodeCacheSize?

Kann mir bitte jemand erklären, was die JVM-Option ist ReservedCodeCacheSize und InitialCodeCacheSize sind? Wann/warum sollte ich es ändern? Wie entscheide ich, welche Größe die richtige ist?

Das sagen die Dokumente:

-XX:ReservedCodeCacheSize=32m Reservierte Code-Cache-Größe (in Byte) – maximale Code-Cache-Größe. [Solaris 64-bit, amd64, and -server x86: 2048m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]

ReservedCodeCacheSize (und InitialCodeCacheSize) ist eine Option für den (just-in-time) Compiler der Java Hotspot VM. Im Grunde legt es die maximale Größe für den Code-Cache des Compilers fest.

Der Cache kann voll werden, was zu Warnungen wie den folgenden führt:

Java HotSpot(TM) 64-Bit Server VM-Warnung: CodeCache ist voll.  Compiler wurde deaktiviert.  Java HotSpot(TM) 64-Bit Server VM Warnung: Versuchen Sie, die Code-Cache-Größe mit -XX:ReservedCodeCacheSize= Code Cache zu erhöhen  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

It’s much worse when followed by Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

When to set this option?

1. when having Hotspot compiler failures
2. to reduce memory needed by the JVM (and hence risking JIT compiler failures)

Normally you’d not change this value. I think the default values are quite good balanced because this problems occur on very rare occasions only (in my experince).

@jeha beantwortet alles, was ich von dieser Frage wissen wollte, abgesehen davon, auf welchen Wert die Parameter eingestellt werden sollen. Da ich den Code, den ich bereitstellte, nicht geschrieben habe, hatte ich nicht viel Einblick in den Speicherbedarf, den er hatte.

Sie können jedoch jconsole zum Anhängen an Ihren laufenden Java-Prozess verwenden und dann die Registerkarte „Speicher“ verwenden, um die Größe des Code-Cache herauszufinden. Der Vollständigkeit halber sind die Schritte (Linux-VM-Umgebung, obwohl ich sicher bin, dass andere Umgebungen ähnlich sind):

1. Starten Sie jconsole auf Ihrem Computer
2. Finden Sie die richtige Prozess-ID und hängen Sie jconsole an (dies dauert einige Augenblicke).
3. Navigieren Sie zur Registerkarte „Speicher“.
4. Wählen Sie aus der Dropdown-Liste „Chart:“ die Option „Memory Pool „Code Cache““ aus.

5. Auch hier kann es einige Augenblicke dauern, bis der Bildschirm aktualisiert wird, und dann sollten Sie Folgendes sehen:
   

   Wie Sie sehen können, verwendet mein Code-Cache ca. 49 MB. Zu diesem Zeitpunkt hatte ich noch den Standardwert, der laut Dokumentation (und @jeha) 48 MB beträgt. Sicherlich eine große Motivation für mich, die Einstellung zu erhöhen!

   Ben.

   ---

   1024 MB standardmäßig waren wahrscheinlich übertrieben, aber 48 MB standardmäßig scheinen zu wenig zu sein …

Eine gute Lernerfahrung vom Indeed-Engineering-Team und Herausforderungen, denen sie bei der Migration zu jdk 8 gegenüberstanden.

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

Fazit: JDK 8 benötigt mehr Code-Cache als JDK 7

Die Standard-Codecache-Größe für JRE 8 beträgt etwa 250 MB, etwa fünfmal so viel wie die Standardgröße von 48 MB für JRE 7. Unserer Erfahrung nach benötigt JRE 8 diesen zusätzlichen Codecache. Wir haben bisher etwa zehn Dienste auf JRE 8 umgestellt, und alle verbrauchen etwa viermal mehr Codecache als zuvor.

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

Im Folgenden sind zwei bekannte Probleme in jdk7u4+ in Bezug auf das Leeren des CodeCache aufgeführt:

1. Der Compiler wird möglicherweise auch dann nicht neu gestartet, wenn die CodeCache-Belegung nach der Notfallspülung auf fast die Hälfte gesunken ist.
2. Die Notfallspülung kann eine hohe CPU-Auslastung durch die Compiler-Threads verursachen, was zu einer Verschlechterung der Gesamtleistung führt.

Dieses Leistungsproblem und das Problem, dass der Compiler nicht wieder aktiviert wird, wurde in JDK8 behoben. Um dies in JDK7u4+ zu umgehen, können wir die Code-Cache-Größe mit der Option ReservedCodeCacheSize erhöhen, indem wir sie auf einen Wert setzen, der größer ist als der Fußabdruck des kompilierten Codes, sodass der CodeCache nie voll wird. Eine andere Lösung besteht darin, das CodeCache Flushing mit der JVM-Option -XX:-UseCodeCacheFlushing zu deaktivieren.

Die oben genannten Probleme wurden in JDK8 und seinen Updates behoben.

Diese Informationen könnten also für Systeme erwähnenswert sein, die auf JDK 6 (mit deaktiviertem Code-Flushing) und 7 ausgeführt werden.