Ciao, On Sat, May 4, 2019 at 8:17 PM [email protected] [it-torino-java-jug] <[email protected]> wrote: > Bingo, con puntatori a 64 bit sono 64 bit in più per oggetto, non pochi. Per > come descrivono l'algoritmo sembra comunque che questi 4 byte non finiscano > nella cache, ma questo per me è solo un altro punto da appurare. > Nel caso di puntatori a 32 bit sono 32 bit in più per ogni oggetto, d'altra > parte ZGC aggiunge 32 per ogni riferimento (tutti i puntatori sono a 64 bit). > Se prendiamo per buono che 32gb siano equivalenti a 48gb > (https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/), > allora sarebbe un 25% di memoria in più, o un 25% di stack o di cache in > meno.
No. Hanno introdotto string deduplication apposta e se hai mai fatto profiling di un'applicazione avrai notato che le maggiori allocazioni sono quelle di byte[], int[], ecc. Il forward pointer viene ammortizzato per gli array, che sono la gran parte di quello che c'è nello heap (stringhe, ecc.). Qui trovi Shipilev che parla del 5-10% in media: https://shipilev.net/talks/vmm-Sep2017-shenandoah.pdf -- 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
