http://www.google.co.in/gwt/x?source=m&u=http%3A%2F%2Fpublib.boulder.ibm.com/infocenter/realtime/v2r0/topic/com.ibm.rt.doc.20/diag/tools/jitpd_aot_fail.html&wsi=89ce4db225e3d6ff&ei=aetSTKyOFZGguQPu8LGmAw&wsc=ti
have a look at this too... jd On 7/30/10, Stuart McCulloch <[email protected]> wrote: > 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. > > -- 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.
