Presented by David Dagastine, Brian Dohert (Sun) including materials on benchmarks for the current JVMs out there. Not directly useful to day-to-day implementation but useful to know how they�ve really optimized using dynamic tuning so that hand tuning of the JVM is less necessary. They quote that on all the benchmarks (ok, benchmarks != real world) they can only eek out at most 5% improvement by hand tuning the JVM options!!!

Java performance analysis is harder, lot more variability under the covers compared to C/C++ (analyzing the JVM layer); must approach statistically; dynamic JIT compiler, garbage collection, thread scheduling, etc.

We do analysis by using Student�s T-Test
� Determine the probability that two data sets are from the same population (p-value)

Beware the Micro-Benchmark
� Make sure you understand what you are measuring (e.g. for testing writes: disk cache settings, processor speed, num processors, etc)
� Interesting, runtime compilation generally occurs in a separate thread (-Xbatch option force compilation to occur sequentially in thread requesting compilation)
� Always ensure you warm up your benchmark
� Use �XX:+PrintCompilation flag
o Verify that no compilation is occurring during measurement interval

Watch out for platform differences
� Heap size
� Garbage collection policy
� -client/-server ergonomics
o �client is default on 32-bit Windows
o �server is default on Solaris/Linux when there are 2 or more processors AND 2GB or more of RAM
� Compilation policy
o �Xbatch is default on 32-bit Windows
� If results look too good to be true, they probably are.

Different JVMs have different RAS performance (Reliability, availability, and serviceability)

J2SE 5.0 foci
� Language features
� Performance
o Out of the box server performance (-server ergonomics)
o Client startup and footprint
o We want our JVM system to tune things dynamically, you worry less about performance
� Quality
o 8000 bug fixes in Tiger!!!
o Far more number of test cases (compatibility, performance, etc)

Client performance
� Sun JVM (on Windows) has smallest footprint and fastest startup
o Note, comparing Sun client based JVM to IBM/BEA�s server JVMs which is a bit misleading, all out of the box, no options.
o JVM Footprint (small -> large): Sun J2SE 1.4.2; Sun J2SE 5.0; JSE 6; (huge step up) IBM 1.4.2; BEA 1.4.2; (really high) BEA 5.0
o JVM startup: (small -> large): Sun J2SE 5.0; Sun JSE 6; Sun J2SE 1.4.2; IBM 1.4.2; BEA 1.4.2; BEA 5.0

� BEA 5.0 was worst in all benchmarks.
� Sun JVM startup (particularly on J2SE 5.0 and JSE 7)
� BEA does compilation at startup vs HotSpot where compilation occurs when the code is first used

� Class Data Sharing not enabled for �-server�

Server performance
� Out-of-box; we are spending our time focusing on dynamic tuning so in many cases you don�t have to
� Under our latest HotSpot JVM the best hand tuning (vs default JVM startup options) you can get is 5% under all the benchmarks!!!
� Competitive performance options based on tuning found at: http://www.spec.org
� Under 64-bit JRockit 5.0 is only beat by IBM 1.4.2 and Sun JSE 6 (J2SE is about 20% slower)
� For J2SE 5.0 their extensive tuning options were: -Xbatdch �Xms1600m �Xmx1600m �XX+AggressiveHeap �Xss128k

HotSpot Server Tuning Recommendations
� Use large pages
o Before J2SE 5.0
� No good options on Linux and Windows
o J2SE 5.0 and beyond
� Use �XX:+UseLargePages on Linux and Windows
� Limit ParallelGC threads when running multiple JVMs on a large box
o Make sure total number of GC threads <= the number of cores/CPUs
� Don�t use AggressiveHeap with J2SE 5.0 or later
o Just increase heap size (if needed); default heap size is up to 1GB on server class machines
� Do use the �-server� flag