Cosa causa una perdita della cache del codice JRE 6 JRE?

Dal passaggio a JRE 6, l'utilizzo della cache del codice del mio server (non heap) continua a crescere indefinitamente. La mia applicazione crea molte classi in fase di esecuzione, MA queste classi vengono scaricate con successo durante il processo GC. Posso vedere queste classi scaricarsi nei log gc e anche l'utilizzo di permGen rimane costante. In particolare, mi assicuro nel mio codice che queste classi siano orfane una volta che ho finito con loro e quindi ottengono correttamente i dati raccolti da permGen.Cosa causa una perdita della cache del codice JRE 6 JRE?

La cache di codice tuttavia continua a crescere. Mi sono reso conto della cache del codice solo dopo il passaggio a JRE 6. Quindi suppongo che le mie domande siano:

Il GC include la cache del codice?
Cosa potrebbe causare una perdita di memoria della cache del codice, in particolare.
C'è un bug in JDK 6 in quest'area?

fonte

2009-10-18 Arturo Knight

Hai provato limitare la dimensione massima con il XX: ReservedCodeCacheSize bandiera runtime? – serg10

Ciao. sì, l'ho appena fatto, rimanda l'inevitabile. Suppongo che sto cercando di capire per cosa viene usata la cache del codice e in che modo nel tuo codice puoi causare una perdita di memoria in quest'area specifica dell'architettura della memoria JVM. Tutti gli altri segmenti della memoria JVM stanno recuperando dati inutili e sono stabili. È solo la cache del codice che sta crescendo indefinitamente e non so perché. Grazie. –

Stai utilizzando un server applicazioni per eseguire il tuo codice o eseguirlo direttamente? – GaZ

È possibile invocare jvisualvm (nel JDK) rispetto all'applicazione problematica? Potrebbe facilmente renderti più saggio su ciò che sta accadendo.

fonte

2009-10-18 21:28:35

Uso jconcole che mi dice tutto ciò di cui ho bisogno. So che la cache del codice sta crescendo indefinitamente. Sto cercando di capire perché, nessuna visualizzazione del codice JVM mi dirà che presumo? Grazie per il tuo commento. –

Si consiglia di guardare attraverso la discussione e basta andare a ritroso per vedere quello che può essere utile nel cercare di limitare questo in giù: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-January/000530.html

Questo comporta JDK5 ma possono essere utili: http://www.nabble.com/Java-code-cache-memory-td22202283.html

Lo stai usando per compilare pagine jsp o qualcosa di simile? In caso contrario, cosa viene compilato dopo l'avvio dell'applicazione? Stai usando AspectJ con la tessitura a runtime?

Sarebbe utile sapere cosa si sta facendo per avere un'idea migliore su come aiutare.

Inoltre, quando la cache del codice è esaurita, non si limita a compilare di nuovo o fa jvm in crash? Mi aspetterei il primo.

Stai usando il JDK di Sun? Immagino che tu sia dal momento che dubito che gli altri siano elencati come versione 6, ma non fa male a chiedere.

fonte

2009-10-19 01:08:57

Grazie. Sto usando modelli di velocità per generare e compilare periodicamente il codice java nel sistema. Usiamo un sistema in cui la configurazione del sistema viene specificata nei fogli di calcolo Excel e quando l'utente cambia i fogli di calcolo Excel, noi rigeneriamo il codice java in base alla configurazione e ricompiliamo in fase di esecuzione, all'interno del sistema. Pertanto, abbiamo più versioni di codice java. So che queste versioni stanno ottenendo gc da permGen poiché posso vederlo nei log gc. La JVM si blocca, ma probabilmente a causa di problemi con JVM. Sì, usando JDK 6. Vedremo i link, grazie. –

Mi chiedevo se il nuovo G1 Garbage Collector (a partire da Java 6 aggiornamento 14) potrebbe aiutarti. Puoi provarlo con -XX: + UnlockExperimentalVMOptions -XX: + UseG1GC, tuttavia secondo lo comments on Jon Masamitsu's blog non lo farà (se il problema è dovuto alla cache del codice). Ma forse la discussione lì o i collegamenti da esso potrebbero aiutare.

fonte

2009-10-19 13:29:21 GaZ

Dai commenti in questo post del blog: http://blogs.oracle.com/jonthecollector/entry/our_collectors

codice viene sfrattato quando le classi vengono scaricati (come bene, come quando i metodi sono "invalidato", vale a dire, alcune ipotesi sono state fatte durante la loro compilation che non reggere più)

se fossi in grado di eseguire un carico di lavoro, prendere un dump dell'heap e controllare se tutte le classi sono gc'd che ci si aspetta di essere.

fonte

2010-04-16 19:12:17 Ron

Due possibili luoghi vorrei cercare il problema: Caricatori trapelati e internamento di stringhe massive.

Dalla descrizione della tua app, verosimilmente verificherei se le vecchie classi generate vengono scaricate dal GC.

Non penso che jConsole abbia un modo per visualizzarlo, ma se riesci a ottenere una copia di YourKit, ha un modo grafico per rilevare entrambi i problemi precedenti.

fonte

2012-01-11 00:02:22

In che modo un massiccio interning delle stringhe interferisce con la cache del codice? Le stringhe sono memorizzate in perm gen e la cache di codice è una regione separata. – Puneet

no, ma è possibile utilizzare -XX: + bandiera UseCodeCacheFlushing per lasciare che la JVM smaltire parte del codice compilato quando il codice di cache si riempie, anche se non è così utile a volte. prova -XX: ReservedCodeCacheSize e -XX: CompileThreshold.
implementazioni caldi di volta in volta, ecc

vedere di più: https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-4-heap-tuning/

fonte

2013-10-15 12:50:13 mysh

Cosa causa una perdita della cache del codice JRE 6 JRE?

risposta

Problemi correlati