I'll still claim it's non-deterministic, you can not possibly know certain aspects of the hardware (word length, branch predictor, hyper- treading/pipeline-swap support, CAS-support etc.) and software (which gen an object is in, what will be inlined, which compacting strategy, where there are safe-points, context-switches and write-barriers).
Don't get me wrong, that's the wonder of the JVM/JIT. But sometimes it would be nice to be able to just rely on AOT compilation so you'd truly know what you are getting. Btw. I never really understood why the JVM doesn't just cache an already JIT'ed memory image which can then just be loaded next time without verifier and profiler running, especially when running stuff in client-mode. /Casper On Jul 29, 10:58 am, Kirk <[email protected]> wrote: > 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.
