On Apr 2, 2008, at 12:55 PM, Vladimir Sizikov wrote: > Here's a slightly reduced example, with most important tings in just > two lines, one marked SLOW and another marked FAST.
Hotspot has optimizations specifically for codes that look like micro- benchmarks, but there are better ways to get performance, and to measure it. Part of the Trouble here is that the Thread.run methods never exit. The compiler kicks in part of the way through, and replaces the interpreter frame with a compiled frame. (The technique is called OSR, or on-stack replacement.) The code is only partially optimized as a result. The difference between releases could be due to a subtle change in tuning of OSR, and would be irrelevant except for micro-benchmarks. Here are some rules, in priority order, to know about when you write micro-benchmarks: Rule 0: Read a reputable paper on JVMs and micro-benchmarking. I suggest Brian Goetz, 2005: http://www-128.ibm.com/developerworks/java/library/j-jtp02225.html? ca=drs-j0805 . Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.) Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase. Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase. Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. -XX:+PrintCompilation reports OSR compilations with an at-sign to denote the non-initial entry point: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance. Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside the of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effect. Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects. Best wishes, -- John P.S. Here's another recent discussion about micro-benchmarks: http://mail.openjdk.java.net/pipermail/hotspot-dev/2008-February/ 000254.html Googling popped this up, which looks good: http://www.concentric.net/~Ttwang/tech/microbench.htm Here's a wiki about low-level information about Hotspot optimizations: http://wikis.sun.com/display/HotSpotInternals/PerformanceTechniques --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
