On Jul 29, 2010, at 10:45 AM, Ben Schulz wrote: > On 29 Jul., 10:15, Kirk <[email protected]> wrote: >> Nonsense.. :-) You may not understand what is going on but that doesn't mean >> it's not deterministic, very very deterministic. > A small excerpt from Josh Bloch's "Mind the Semantic Gap"[1]: >> [W]hen it does come time to optimize, the process is greatly complicated by >> the semantic gap. Consider this: Suppose you carefully write a well-designed >> microbenchmark that does everything right (e.g., warms up the VM, ensures >> that computation is not optimized away, times a sufficient amount of >> computation, does multiple timings to ensure repeatability). You run the >> benchmark, and see that after warmup, every run takes nearly the same amount >> of time. Happiness? You run the benchmark again, and again every run takes >> the same amount of time, but it's a different amount! You run the program >> twenty times, and see the results clustering into several groups, but always >> consistent within a program-run. What is going on? >> >> In modern VMs such as HotSpot, the task of deciding what to inline and when >> to inline it is performed by a background thread (at runtime). This process >> is called "compilation planning." Because it's multithreaded, it's >> nondeterministic.
This isn't my experience.. I've found HotSpot to be very predictable. Case in point, I recently helped a client diagnose a luke-warm method problem related to hotspot compilation. We were able to completely predict if and when a key method would be compiled along with how it would be compiled. The effect that Josh is talking about is common when the execution profile changes over time. HotSpot decompiles, remeasures and then recompiles. One other point, microbenchmarking almost always involves creating code that confuses HotSpot so that it cannot apply the optimizations that would normally be applied. IOWs, it's not production code and the effects in production may be different than those found in the benchmark. To Josh's point, figuring out when these changes may happen isn't easy but it's not impossible. Regards, Kirk -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
