Your pulling my crank
Is it me or is it odd that Google has a penchant for naming it's stuff after bits of dino-juice burning automobiles? At least I understand a "V8" engine but a "Crankshaft" engine? As opposed to what, a turbine perhaps. What happened to going green? Where is the "solar flair" or the "aerogenerative thermantidote"? So I ask you, will the next great GOOG tweak be something useful for the fool injected masses or will the whole naming convention backfire like a pool of raw gas in the carburetor?
It's just me, isn't it. Oh, yes, another margarita will do nicely, thanks.
Re: Your (sic) pulling my crank
I'm guessing that the whole shebang is still the V8 engine and Crankshaft is the adaptive compilation bit.
i.e. A V8 has a Crankshaft in it. Geddit? We'll probably see bits called "Piston", "Big end", "Sump" and "Gudgeon pin" soon.....
Why not just feed the whole damn thing into the optimizing compiler. It's not like webpages have the entire Windows codebase to build every time you reload the thing. It would take milliseconds at most to deep compile your average java source file, less time than it would take to download all the images used on the page.
It doesnt work that way. You cant just feed it all in to a compiler with optimization at max and expect to get good results. In dynamic environments the compiler just doesnt have enough information to make good optimizations straight away. Remember theres no type information. Profiling is not just about identifying parts of code that run often, but recording common code paths so the compiler can generate special-case code for them. For example it can notice that a particular call site always seems to go to one particular function, so it can inline the call. You cant determine that without running the code for a while first. What this crankshaft will do is compile a basic version initially, use that to profile, then "deopt" and recompile with the information it gained. Java's hotspot pioneered this.
Lars is a leading expert in the field. He knows what hes doing.
Try loading a 100+ shopping cart+info list which is being loaded via Jquery.
Examples of worst offenders: dabs.com and lovefilm.com
It takes it half a minute to update a page on a machine which is with less than a MB of cache and/or is running at less than a GHz during which time the machine flatlines at 100% CPU usage. Actually I am not being fair here. Dabs when they released the new UI was totally unusable on anything short of a 3GHz monster. They have tweaked it a bit so it is just about tolerable now.
In any case, on a page like this there are 3-4 pieces of code that are running nearly constantly and eating most of the CPU. The rest gets executed only if you click, mouseover or do something specific with a specific item. So using hotspot for this makes lots of sense.
The more interesting bit here is the IPR. IIRC, Sun patented a lot of stuff around hostpotting., There are a couple of IBM patents as well. Google is yet to answer on how does the crankshaft manage to avoid this.
Oracle will sue the hell out of them
I believe Java Hotspot technology is quite heavily guarded with patents now owned by Oracle.
I am quite sure Ellison is now planning a new lawsuit against all of the browser vendors using anything similar to Hotspot.
Patents vs realistic lawsuits
I'm not a patent troll, nor I play one on TV, but that would surprise me. Sun-now-Oracle's HotSpot is heavily based on earlier academic research, so establishing prior art for a lot of the core technology should be as simple as consulting Craig Chamber's PhD thesis. This Dr. Chambers now works at Google, incidentally...
Why not use the real hotspot instead of reimplementing one?