Ciao Simone, condivido le tue osservazioni, ma le mie considerazioni sono diverse.
L'impressione che ho è che Z sia un progetto meno maturo di Shenandoah, da qui la sua semplicità. Sicuramente migliorerà con il tempo ma questo vale anche per Shenandoah. Con questa maggior sofisticazione c'è anche il rischio di complicarsi la vita e di effettuare un tuning o scegliere delle configurazioni non ottimali. Questo rischio c'è per tutti i GC di Java, G1 ha molti parametri difficili da impostare ma è comunque utilizzato proficuamente. Se non hai problemi di RAM, imposti uno heap generoso e ZGC fa il resto. Se non ho problemi di RAM, imposto un heap generoso e Epsilon fa il resto :) Battute a parte credo che questo valga per tutti i GC. Da qui l'impostare uno heap generoso e sempre da qui forse gran parte della sofisticazione di Shenandoah è qualcosa che magari non userai mai. Condivido, ma dovendo optare tra un GC che funziona sempre ed un crash in produzione la scelta è facile. Nei miei benchmark, ZGC ha sempre avuto pause STW più corte di Shenandoah. Parliamo di 2 ms per ZGC contro 4 ms di Shenandoah contro 40 ms di G1. Interessante, hai misurato anche il carico sulla CPU o altro? Z comunque ha un problema non banale: il mancato supporto dei compressed oops. Gli heap minori di 32gb non sono rari, in questo caso Z richiede sensibilmente più memoria di G1. Viceversa sopra i 32gb Shenandoah alloca di più di Z e sembra avere pause maggiori. L'allocazione può sembrare un problema secondario ma strutture dati più grandi comportano di fatto meno oggetti nella cache L1. Per me la sfida resta aperta. Grazie ancora, Francesco ---In [email protected], <simone.bordet@...> wrote : Ciao, On Fri, May 3, 2019 at 9:54 PM francesco_v@... mailto:francesco_v@... [it-torino-java-jug] <[email protected] mailto:[email protected]> wrote: > Ciao, > > mi sto interessando ai nuovi GC per JVM grazie anche all'ottima introduzione > di Simone. > > Ho l'impressione che ci sia ancora poca letteratura a riguardo, tra cui > molti articoli copia-incolla (spesso senza citare le fonti). > > > Volevo approfondire la questione, farmi una idea più precisa e poter > comprendere meglio come, sul campo, si differenziano queste nuove soluzioni > (specialmente in termini di prestazioni che dipendono da molteplici fattori). > > > Ad oggi sono diventato simpatizzante di Shenandoah, ho l'impressione sia > decisamente più maturo (e pronto per la produzione) di ZGC, praticamente una > scelta obbligata con JVM pre 12, per heap fino a 32 GB o superiori ai 4 TB, > forse anche preferibile in architetture non Sparc. La mia impressione è che Shenandoah sia più sofisticato di ZGC. C'è più attenzione ai casi estremi dove il GC è in difficoltà a causa della mancanza di memoria, c'è la possibilità di specificare delle euristiche diverse, ecc. Con questa maggior sofisticazione c'è anche il rischio di complicarsi la vita e di effettuare un tuning o scegliere delle configurazioni non ottimali. Secondo me il plus di ZGC è la sua semplicità. Se non hai problemi di RAM, imposti uno heap generoso e ZGC fa il resto. Per tutti i GC, e quindi anche per Shenandoah e ZGC non vuoi mai arrivare alla condizione in cui il GC è al limite e sta per finire in FullGC o in allocation stall. Da qui l'impostare uno heap generoso e sempre da qui forse gran parte della sofisticazione di Shenandoah è qualcosa che magari non userai mai. Il plus di Shenandoah è il fatto che sia disponibile per JDK 8+ e per tutte le piattaforme. ZGC è solo per Linux x86_64 e stanno facendo il port su ARM (AArch64, sperano di finirlo in tempo per JDK 13, c'è una deadline a metà Giugno). Nei miei benchmark, ZGC ha sempre avuto pause STW più corte di Shenandoah. Parliamo di 2 ms per ZGC contro 4 ms di Shenandoah contro 40 ms di G1. Quindi sembra che ZGC sia il doppio meglio di Shenandoah, ma parliamo di valori assoluti molto piccoli in entrambi i casi. A questo punto secondo me G1 è superato. Non vedo nessun motivo di usare G1 quando puoi usare Shenandoah o ZGC. Penso che il throughput sia paragonabile ma G1 ha delle pause STW molto più lunghe. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
