Too Big To Fall

Jeg (Søren) havde håbet jeg kunne crashe Project Lambda sessionen, men en pænt lang kø, fik mig tilbage til min bookede session.

En session som gik rent på optimering af JVM, ud fra en liste af tips for at optimere JVM’er og anvendelsen af disse, han underbyggede alle eksemplerne med resultater fra performance målinger.

1. Tip #1 – Tænd for COOPS , hvis man har rigtig store Heaps
2. Tip #2 – Tænd for NUMA (Non Unfiform Memory Access),  hvis man kører RHEL 6, kræver glibc 2.6, skulle gøre det meget nemmere at skalere.
3. Tip #3 – Del Read-only data. Deling af statisk read only data mellem flere JRE uden at lide performance, kan klares ved at bruge. NewDirectByteBuffer class, som er noget JNI der gør at man kan dele data i memory.
4. Tip #4 – Del nanoTime med C . Brug System.nanoTime() eller native clock_gettime(), hvis man har brug for fuldstændig præcis timing mellem java kode og c/c++ kode.
5. Tip #5 – Use hprof. hprof er virkelig en juvel, man kan se alt muligt om ens applikation med minimal indsats. en kommando og så profileres der. -Xrunhprof. viser sig at f.eks. jar kommandoen har haft masser af problemer, fordi den kaldte Hashtable.contains() , helt vildt mange gange. så tip nr 5 er et af de aller vigtigste for at optimere.
6. Tip #6 – Slå inlining off for hprof. ved at slå inlining fra, kan det være nemmere at få et mere præcist output fra hprof. compileren inliner jo metoder, men det er svært at læse når man læser output fra hprof. Så det er bedre at slå det fra under profiling.. -XX:-Inline. MEN ! gør det ikke i prod.
7. Tip #7 . Pas på identitet hashcode : For at reducerer fuld GC tid og reducere resident tid. Undgå at kalde System.identityHashCode(), som JVM’en bl.a. bruger ved serialisering. når man serialiserer objekter vil alle disse have identityHashCode og de vil blive liggende for altid, så længer man holder objektet man serialiseree. Den gemmer identity hashes i mark word, som i virkeligheden bruges af GC. så ved GC flyttes alle identityHashCodes til andet sted på heap så kører GC og så kopieres alt tilbage bagefter. Det er jo ret interessant. så basically siger han jo, dont serialize. key point er at det sker og der er ikke noget at gøre.

Må erkende at det ikke lige er mig, med sådan noget JVM optimering, det er lidt for maskinnært , men det var ok med lidt information om hvad man bl.a. kan gøre og jeg syntes at pointerne omkring tip 7 jo er ret vigtige, hvis man serialiserer meget. hmmm.. det lyder da ikke så godt at serialisering fører til voksende mængde af objekter man ikke kan slippe af med.

Må nok lige læse lidt mere om det.