Mandelin: Starting JägerMonkey [LWN.net]

Mandelin: Starting JägerMonkey

Posted Feb 28, 2010 18:22 UTC (Sun) by bboissin (subscriber, #29506) [Link]

SpiderMonkey and JaegerMonkey are supposed to work together (the latter just
handles untraced code).

Mandelin: Starting JägerMonkey

Posted Mar 1, 2010 14:02 UTC (Mon) by nick.lowe (guest, #54609) [Link]

In which case, why not just JIT compile the lot and don't bother tracing?

Mandelin: Starting JägerMonkey

Posted Mar 1, 2010 14:09 UTC (Mon) by bboissin (subscriber, #29506) [Link]

Tracing will identify hot loops that are worth re-optimizing (the cases
where the time spent compiling is actually worthwhile).

Mandelin: Starting JägerMonkey

Posted Mar 1, 2010 15:21 UTC (Mon) by bjacob (subscriber, #58566) [Link]

Tracing means analyze the actual types of the variables at hand, and compile code tailored for these specific data types. This allows, theoretically, to compile code that's as fast as if javascript were a statically-typed language.

Mandelin: Starting JägerMonkey

Posted Mar 4, 2010 9:26 UTC (Thu) by elanthis (guest, #6227) [Link]

It has nothing to do with matching the speed of a statically typed
language. Tracing techniques were originally developed for a statically
typed language: Java.

Hardware-level tracing could improve the flow of a C or C++ app, for
example. It's about removing branches, inlining code based on actual
execution paths, and otherwise optimizing out repeated calculations. It is
basically a runtime equivalent of profile-guided optimization.

In fact, the dynamic nature of JavaScript makes it impossible for its
tracing implementation to match the tracing potential of something like
Java because the resulting machine code for JavaScript still requires type
guards in any non-trivial chunk of code (that is, machine code that checks
if types of return values to non-traceable functions or global/external
data are different than expected and execution needs to be thrown back to
the interpreter or non-traced JIT'd machine code).

The downside of tracing is, of course, that it incurs a bunch of extra
overhead for all execution, including code paths that won't actually
benefit from being traced (the tracer won't actually know that unless it
analyzes the code path, though). This is in part why V8 and WebKit's JS
engine are consistently outperforming TraceMonkey. The potential for
tracing is quite high but the implementation requires a LOT more fine
tuning to make sure it has very little overhead.

This is similar to how most script languages have very bad optimization
passes in their compilers (if they have any optimization pass at all) in
order to ensure that the source code the app is distributed as can quickly
be turned into executable bytecode to ensure that the app starts up
quickly. This in turn makes script languages actually pretty crappy for
general app development when speed is actually important because it's far
more useful to the user to have the app shipped in a precompiled and
heavily optimized format (which is exactly what your C/C++/.NET/Java/etc.
apps are, of course).

Engines like those used for JavaScript rely on simply transforming the
source code into machine code in an almost direct fashion. These
techniques are negating the interpreter overhead but aren't in any way
closing the performance gap with the output a good compiler for a "real"
language creates thanks to sophisticated optimization passes. JavaScript
is optimized for web browsers where scripts are delivered as source code,
however, so it can't really afford to have a 30 second compilation for
jquery.js or what have you. If you're looking to use a script language as
an embedded runtime for something performance critical where you aren't
needing to quickly execute arbitrary source, though, you may find yourself
far better off using embedded Mono or embedded Java and shipping your
scripts in a precompiled and heavily optimized form.

Mandelin: Starting JägerMonkey

Posted Mar 4, 2010 13:33 UTC (Thu) by bjacob (subscriber, #58566) [Link]

Just FYI,

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

Quotes: "Why its hard to run JS fast: dynamic typing"

"Our goal in TraceMonkey is to compile type-specialized code. To do that, TraceMonkey needs to know the types of variables."

"If we let the program run for a bit in an interpreter, the engine can directly observe the types of values. Then, the engine can use those types to compile fast type-specialized code."

I guess that "tracing" can mean different things. If I understand well this article, in the context of TraceMonkey, it really is about detecting the actual types used in the execution of a dynamically-typed language, in order to generate type-specialized code i.e. code that can be as fast as a statically typed language.

The origin of tracing techniques

Posted Mar 6, 2010 15:13 UTC (Sat) by anton (guest, #25547) [Link]

Once upon a time there was trace scheduling, a static technique for performing (micro)instruction scheduling across basic blocks; a trace was a sequence of code that could be entered and exited in multiple places. That was later simplified into superblock scheduling (a superblock can be entered only at the top). Then came dynamic traces (actually superblocks) for dynamic optimization (from machine code to machine code), which showed the usefulness of this concept in a dynamic context. These ideas were then used for JIT compilation of JavaVM code, and finally for JavaScript and other dynamic languages.