Quali sono le migliori impostazioni di garbage collection per il lato client?

Question

Le JVM recenti hanno molti parametri XX per la garbage collection (vedere here per esempio), ma quali sono le opzioni che possono rendere l'applicazione Swing lato client davvero migliore?

Devo notare che una delle cose che mi infastidisce davvero sulle applicazioni java lato client è il grande ritardo nella raccolta dati obsoleti di stop-the-world. In Intelli-J IDEA l'ho visto passare tre minuti o più.

EDIT: Grazie per tutte le risposte. Solo per segnalare che ho messo il garbage collector CMS per IDEA (che è un buon riferimento comune del tipo di applicazione a cui la maggior parte di tutti coloro che leggono questa domanda ha familiarità) usando l'impostazione suggerita da here. Ho anche impostato -XX: + StringCache per vedere se avrebbe ridotto i requisiti di memoria.

In generale, l'osservazione è che le prestazioni di corsa regolari non sono degradate al punto che si può notare guardandolo. La riduzione della memoria è enorme utilizzando l'opzione Cache stringa, tuttavia il metodo CMS non è completo e termina per richiedere l'interruzione del ciclo di garbage collection mondiale (di nuovo ai tre minuti di attesa) per cancellare la memoria (400 MB in una corsa) .

Tuttavia, dato il ridotto ingombro di memoria, potrei essere in grado di mettere solo una piccola quantità massima di memoria che manterrà il fermo delle collezioni mondiali di dimensioni più piccole.

IDEA 8.1.4 viene fornito con JDK 1.6.0_12, quindi non ho ancora provato G1. Inoltre, la mia macchina ha solo 2 core, quindi un approccio G1 non sarà massimizzato. È ora di colpire il boss per una macchina migliore;).

Answer 1

Non c'è una sola risposta a questa domanda, dipende molto da cosa sta facendo l'applicazione e da come gestisce i suoi oggetti. Forse dare un'occhiata a How does garbage collection work e Parallel and concurrent garbage collectors per capire le varie opzioni.

Quindi, controllare il documento Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning che espande i concetti e le tecniche di ottimizzazione GC per Java SE 6 che sono stati introdotti nel documento Tuning Garbage Collection with the 5.0 Java Virtual Machine.

Se si desidera mantenere brevi le pause della raccolta di dati inutili, è probabile che il collector simultaneo sia nella giusta direzione poiché esegue la maggior parte del suo lavoro contemporaneamente (vale a dire, mentre l'applicazione è ancora in esecuzione). Ma trovare la migliore configurazione richiederà la profilazione (prendere in considerazione la misurazione del throughput GC, il tempo di pausa massimo e medio, la frequenza dei GC completi e la loro durata).

(EDIT: Dopo aver letto un commento da PO, penso che la lettura My advice on JVM heap tuning, keep your fingers off the knobs! dal guru prestazioni Kirk Pepperdine sarebbe una buona idea.)

Answer 2

La sintonizzazione dell'accumulo di rifiuti è più di un'arte allora scienza, e in realtà dipende dall'applicazione e dal suo utilizzo. Se le strategie standard stop-the-world ti infastidiscono, perché non convertirle in CMS (mark e sweep concorrenti) o nel nuovo G1 collector?

Il modo migliore è modificare i parametri e collegare un profiler per esaminare il comportamento dell'applicazione.

Answer 3

Non esiste un'opzione "migliore" (se ci fosse, qualcuno lo userebbe, giusto?) Ma forse un'opzione che aiuti nel tuo caso. Ma ecco alcuni suggerimenti:

• Utilizzare l'ultima VM. Il codice GC è migliorato con ogni versione.
• Utilizzare il client jvm.dll (disponibile Java sinve 1.5 in jre/bin/client/). Questo dovrebbe essere il default.
• L'allocazione e la liberazione di oggetti in Java sono economiche. È costoso tenerli in giro.

Answer 4

Se si desidera ottenere prestazioni migliori, ridurre il lavoro del garbage collector. Prendi in considerazione l'utilizzo di un pool di oggetti anziché creare e scaricarli costantemente e assicurati di aver bisogno di ogni oggetto che crei.

Answer 5

questo è abbastanza automatico e funziona per noi:

-server -Xss4096k -Xms12G -Xmx12G -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:GCTimeRatio=19 -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=500 -XX:+PrintGCTaskTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintTenuringDistribution -Xloggc:gc.log