yeah their description of JIT may have made sense once, but any jit that goes beyond the initial stage of timing methods would go beyond it pretty quickly.
This is also a good example of a straw man argument (if it was an argument). On the subject though, I don't think its JS performance that hurst RIA/ web apps - its the browsers performance with respect to DOM, not the time spent (in most cases) in script. So I don't think this stuff is much of a big deal for web apps (unless actually JS performance was an issue for you). For most of the world. its dom manipulation which has nothing to do with this (unless they start implementing the browser itself in JS, which is possible). On Sep 1, 12:53 am, Joshua Marinacci <[EMAIL PROTECTED]> wrote: > Hotspot is *not* a traditional JIT compiler. While that was true in > the early days of HotSpot (many years ago) today it does lots of > advanced realtime prediction and analysis. I would say that HotSpot > is the most advanced general purpose VM today, and it's constantly > being improved. Where I see real competition coming is special purpose > VMs; like things that will optimize your code into a pixel shader, or > that do crazy automatic parallelization, or that focus on energy > consumption over everything else. > > I think they just mention Java's VM because it's the one most people > are familiar with. If the CLR was more commonly used they would have > mentioned that instead. :) > > On Aug 31, 2008, at 3:44 AM, sherod wrote: > > > > > Java gets the (usual) dishonorable mention with Mozilla implying that > > their tracing JIT compiler is superior to the JIT solution in Java. > > > Anybody with stronger experience than I with this stuff care to > > comment? > > > *Start quote* > > > Traditional just-in-time compilers (like Sun’s Hotspot VM) are in > > their design and structure very similar to static compilers (like > > GCC). They observe which methods get executed frequently, and > > translate the method into native machine code once a certaint > > threshold has been reached. While such methods often contain > > performance-critical parts (such as loops), they often also contain > > slow paths and non-loopy code, which barely if at all contributes to > > the runtime of the method. A whole-method compiler, however, has to > > always analyze and translate the entire method, even if parts of it > > are not particularly “compilation-worthy”. > > > Trace-based compilation takes a very different approach. We monitor > > the interpretation of bytecode instruction by the virtual machine and > > scan for frequently taken backwards branches, which are an indicator > > for loops in the underlying program. Once we identify such a loop > > start point, we follow the interpreter as it executes the program and > > record the sequence of bytecode instructions that get executed along > > the way. Since we start at a loop header, the interpreter will > > eventually return to this entry point once it completed an iteration > > through the loop. The resulting linear sequence of instructions is > > what we call a trace. > > > *end quote* > > > Rest of the article here: > > >http://www.infoq.com/news/2008/08/tracemonkey --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
