Google 'Crankshaft' inspired by Sun Java HotSpot
Bak to 'adaptive compilation'
Agentless Backup is Not a Myth
Google's new "Crankshaft" JavaScript engine was inspired at least in part by Sun's Java Hotspot performance engine, the reengineered Java virtual machine that Sun released in 1999.
A number of developers who built Crankshaft, including Danish programmer Lars Bak, also worked on HotSpot. Bak led the HotSpot team at Sun, and he's one of the founders of Google's V8 JavaScript engine.
Crankshaft is similar to Mozilla's TraceMonkey-JagerMonkey JavaScript engine setup in that it seeks to optimize certain pieces of code. "At a simple level, they both do dynamic optimization. There's one version of the code that gets 'hot,' gets important, and they take a deeper pass on that code," Google engineer Eric Kay said this morning at the annual Add-on-Con browser conference in Mountain View, California, when we asked about the Crankshaft design and how it compares to Mozilla's engine.
But whereas TraceMonkey uses a technique called "tracing" – detecting code loops and converting them into assembly language – Google's Crankshaft uses an approach known as "adaptive compilation" whereby it identifies all sorts of hot code and optimizes whole methods of code as needed. Sun's HotSpot was based on adaptive compilation, and according to Kay the idea of adding adaptive compilation to the V8 engine has long been on Google's roadmap.
Crankshaft includes four complementary components. In addition to a base compiler, there's a runtime profile that identifies hot code. Then an optimizing compiler recompiles the hot code to offer such optimizations as loop-invariant code motion, linear-scan register allocation, and inlining. Lastly, Google includes "deoptimization support" that identifies cases where the optimizing compiler has promised too much optimization. When this happens, the engine falls back on the base compiler. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Re: *Sigh*
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.
*Sigh*
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.
re: rhino
No, the real hotspot is a virtual machine, originally created for java, but which can be used for a number of languages like python and ruby. Rhino (see title) is a javascript implementation on top of the JVM hosted on mozilla.org. JSR 292 is meant to help with languages like javascript on the JVM.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
