Qualcuno può spiegare cosa sono ReservedCodeCacheSizee quali InitialCodeCacheSizesono le opzioni JVM ? Nello specifico quando / perché dovrei cambiarlo? Come decido qual è la taglia giusta?
Questo è ciò che dicono i documenti:
-XX: ReservedCodeCacheSize = 32m Dimensioni cache del codice riservato (in byte) - dimensione massima della cache del codice. [Solaris 64-bit, amd64 e -server x86: 2048m; in 1.5.0_06 e precedenti, Solaris 64 bit e and64: 1024m.]
Risposte:
ReservedCodeCacheSize(e InitialCodeCacheSize) è un'opzione per il compilatore (just-in-time) della VM Hotspot Java. Fondamentalmente imposta la dimensione massima per la cache del codice del compilatore.
La cache può riempirsi, il che si traduce in avvisi come i seguenti:
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
È molto peggio se seguito da Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.
Quando impostare questa opzione?
Normalmente non cambieresti questo valore. Penso che i valori predefiniti siano abbastanza equilibrati perché questi problemi si verificano solo in occasioni molto rare (nella mia esperienza).
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.]non si conoscono i valori OpenJDK. Un moderato aumento dovrebbe essere sufficiente (l'impostazione precedente di 1024 m era al di là del bene e del male).
@jeha risponde a tutto ciò che volevo sapere da questa domanda, a parte il valore su cui impostare i parametri. Poiché non scrivevo il codice che stavo distribuendo, non avevo molta visibilità sull'impronta di memoria che aveva.
Tuttavia, puoi utilizzare jconsole per collegarti al tuo processo java in esecuzione, quindi utilizzare la scheda "Memoria" per scoprire la dimensione della cache del codice. Per completezza, i passaggi sono (ambiente Linux VM, anche se sono sicuro che altri ambienti sono simili):
Anche in questo caso, potrebbero essere necessari alcuni istanti prima che lo schermo si aggiorni, quindi dovresti vedere qualcosa del tipo:
Come puoi vedere, la mia cache del codice utilizza circa 49 MB. A questo punto avevo ancora il valore predefinito che la documentazione (e @jeha) dice è di 48 MB. Sicuramente una grande motivazione per me per aumentare l'ambientazione!
Ben.
1024 MB di default probabilmente stavano esagerando, ma 48 MB di default sembra che lo stiano indebolendo ...
Una buona esperienza di apprendimento da parte del team di ingegneri di Indeed e le sfide che hanno dovuto affrontare durante la migrazione a jdk 8.
http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/
Conclusione: Jdk 8 necessita di più cache di codice han JDK 7
La dimensione predefinita del codecache per JRE 8 è di circa 250 MB, circa cinque volte più grande del valore predefinito di 48 MB per JRE 7. La nostra esperienza è che JRE 8 necessita di quel codecache aggiuntivo. Finora sono passati circa dieci servizi a JRE 8 e tutti utilizzano circa quattro volte più codecache rispetto a prima.
da https://blogs.oracle.com/poonam/entry/why_do_i_get_message :
I seguenti sono due problemi noti in jdk7u4 + rispetto allo svuotamento di CodeCache:
- Il compilatore potrebbe non essere riavviato anche dopo che l'occupazione di CodeCache è scesa a quasi la metà dopo lo svuotamento di emergenza.
- Lo svuotamento di emergenza può causare un utilizzo elevato della CPU da parte dei thread del compilatore, con conseguente riduzione delle prestazioni complessive.
Questo problema di prestazioni e il problema del compilatore che non viene riattivato di nuovo è stato risolto in JDK8. Per risolvere questi problemi in JDK7u4 +, possiamo aumentare la dimensione della cache del codice utilizzando l'opzione ReservedCodeCacheSize impostandola su un valore maggiore dell'impronta del codice compilato in modo che CodeCache non si riempia mai. Un'altra soluzione a questo è disabilitare il CodeCache Flushing utilizzando l'opzione -XX: -UseCodeCacheFlushing JVM.
I problemi sopra menzionati sono stati risolti in JDK8 e nei suoi aggiornamenti.
Quindi queste informazioni potrebbero valere la pena menzionare per i sistemi in esecuzione su JDK 6 (con lo svuotamento del codice disabilitato) e 7.