On 29 July 2010 17:37, Casper Bang <[email protected]> wrote: > 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. >
you mean something like this? http://publib.boulder.ibm.com/infocenter/realtime/v1r0/topic/com.ibm.rt.doc.10/realtime/sample_running_aot.html AOT compilation has actually been around for several years in specialized JVMs, but has not yet gone mainstream some of the major issues are security, maintaining the cache/versioning, and runtime linking (sorting out offsets, etc.) /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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Cheers, Stuart -- 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.
