Perché Java 10 è raccomandato se stai usando G1 GC?
Java 10 riduce i tempi di pausa GC completi migliorando iterativamente il suo algoritmo esistente.
-XX:ParallelGCThreads
Come ho capito G1 non esegue i suoi cicli di raccolta contemporaneamente alla nostra applicazione. Continuerà a mettere in pausa periodicamente l'applicazione e le pause GC complete aumentano con dimensioni heap più grandi.
Allora come migliora le prestazioni? Qualcuno può spiegare questo?
2 answers
Infatti, Java 11 è consigliato se si utilizza G1GC perché è stato fatto un sacco di lavori su di esso per ridurre il suo ingombro e abbassare le pause rispetto a 10.
È stato fatto un riepilogo sulla mailing list hotspot-gc-use intorno ai vari miglioramenti apportati su 11, 10 e 9 per G1GC, lo potete trovare a questo link: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2018-June/002759.html
Un breve riassunto da questo post sulla lista:
[...] Vorrei sottolineare che nel complesso, con G1, rispetto a JDK8 è possibile ottenere tempi di pausa inferiori del 60% "gratuitamente" su x64 processori (probabilmente più su ARM / PPC a causa di specifici menzionati modifiche), ad un ingombro di memoria altamente ridotto.
Perché non è stato fino a Java 10 che G1GC è diventato completamente parallelo nel ciclo completo di GC stop-the-world. Come da JEP 307: Parallel Full GC per G1 questo migliora la latenza dello scenario peggiore:
Il garbage collector G1 è progettato per evitare raccolte complete, ma quando le raccolte simultanee non possono recuperare la memoria abbastanza velocemente si verificherà un GC completo. L'attuale implementazione del GC completo per G1 utilizza un singolo algoritmo mark-sweep-compact filettato. Noi intende parallelizzare l'algoritmo mark-sweep-compact e utilizzare lo stesso numero di thread delle collezioni Giovani e miste. Il numero di thread può essere controllato dall'opzione-XX: ParallelGCThreads, ma ciò influirà anche sul numero di thread utilizzati per le raccolte giovani e miste.