Editing SpiderMonkey (section)

==Internals==
SpiderMonkey is written in [[C (programming language)|C]]/[[C++]] and contains an [[interpreter (computing)|interpreter]], the WarpMonkey [[just-in-time compilation|JIT compiler]], and a [[garbage collection (computer science)|garbage collector]].

===TraceMonkey===
TraceMonkey<ref>{{cite web |url=https://wiki.mozilla.org/JavaScript:TraceMonkey |title=JavaScript:TraceMonkey, MozillaWiki |access-date=2020-07-22}}</ref> was the first JIT compiler written for the JavaScript language. Initially introduced as an option in a beta release and introduced in Brendan Eich's blog on August 23, 2008,<ref>{{cite web |url=https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/ |title=TraceMonkey: JavaScript Lightspeed, Brendan Eich's Blog |access-date=2020-07-22}}</ref> the compiler became part of the mainline release as part of SpiderMonkey in [[Firefox 3.5]], providing "performance improvements ranging between 20 and 40 times faster" than the baseline interpreter in [[Firefox 3]].<ref>{{cite web |url=https://arstechnica.com/news.ars/post/20080822-firefox-to-get-massive-javascript-performance-boost.html |title=Firefox to get massive JavaScript performance boost |last=Paul |first=Ryan |date=22 August 2008 |publisher=Ars Technica |access-date=21 March 2013 |archive-url=https://web.archive.org/web/20120506204854/http://arstechnica.com/open-source/news/2008/08/firefox-to-get-massive-javascript-performance-boost.ars |archive-date=6 May 2012 |url-status=live |df=dmy-all}}</ref>

Instead of compiling whole functions, TraceMonkey was a [[tracing JIT]], which operates by recording [[control flow]] and [[data type]]s during interpreter execution. This data then informed the construction of [[trace tree]]s, highly specialized paths of [[native code]].

Improvements to JägerMonkey eventually made TraceMonkey obsolete, especially with the development of the SpiderMonkey [[type inference]] engine. TraceMonkey is absent from SpiderMonkey from Firefox 11 onward.<ref>{{cite web |url=http://blog.mozilla.com/nnethercote/2011/11/01/spidermonkey-is-on-a-diet/ |title=SpiderMonkey is on a diet &#124; Nicholas Nethercote |last=Nethercote |first=Nicholas |date=1 November 2011 |publisher=Blog.mozilla.com |access-date=21 March 2013 |archive-url=https://web.archive.org/web/20120328124431/http://blog.mozilla.com/nnethercote/2011/11/01/spidermonkey-is-on-a-diet/ |archive-date=28 March 2012 |url-status=live |df=dmy-all}}</ref>

===JägerMonkey===
JägerMonkey, internally named MethodJIT, was a whole-method JIT compiler designed to improve performance in cases where TraceMonkey could not generate stable [[native code]].<ref>{{cite web|url=http://www.bailopan.net/blog/?p=683|title=JaegerMonkey – Fast JavaScript, Always! » Mystery Bail Theater|date=26 February 2010|publisher=Bailopan.net|access-date=21 March 2013|archive-url=https://web.archive.org/web/20130324172746/http://www.bailopan.net/blog/?p=683|archive-date=24 March 2013|url-status=live|df=dmy-all}}</ref><ref name="hunted">{{cite web|url=https://arstechnica.com/open-source/news/2010/03/mozilla-borrows-from-webkit-to-build-fast-new-js-engine.ars|title=Mozilla borrows from WebKit to build fast new JS engine|last=Paul|first=Ryan|date=9 March 2010|publisher=Ars Technica|access-date=21 March 2013|archive-url=https://web.archive.org/web/20120416171903/http://arstechnica.com/open-source/news/2010/03/mozilla-borrows-from-webkit-to-build-fast-new-js-engine.ars|archive-date=16 April 2012|url-status=live|df=dmy-all}}</ref> It was first released in [[Firefox 4]] and eventually entirely supplanted TraceMonkey. It has itself been replaced by IonMonkey.

JägerMonkey operated very differently from other compilers in its class: While typical compilers worked by constructing and optimizing a [[control-flow graph]] representing the function, JägerMonkey instead operated by iterating linearly forward through SpiderMonkey [[bytecode]], the internal function representation. Although this prohibits optimizations that require instruction reordering, JägerMonkey compiling has the advantage of being very fast, which is useful for JavaScript since recompiling due to changing variable types is frequent.

Mozilla implemented a number of critical optimizations in JägerMonkey, most importantly [[polymorphic inline cache]]s and [[type inference]].<ref>{{cite web|url=https://wiki.mozilla.org/JaegerMonkey|title=JaegerMonkey - MozillaWiki|publisher=Wiki.mozilla.org|access-date=21 March 2013|archive-url=https://web.archive.org/web/20130823045214/https://wiki.mozilla.org/JaegerMonkey|archive-date=23 August 2013|url-status=live|df=dmy-all}}</ref>

The difference between TraceMonkey and JägerMonkey JIT techniques and the need for both was explained in [https://hacks.mozilla.org/2010/03/improving-javascript-performance-with-jagermonkey/ a hacks.mozilla.org article]. A more in-depth explanation of the technical details was provided by Chris Leary, one of SpiderMonkey's developers, [http://blog.cdleary.com/2010/09/picing-on-javascript-for-fun-and-profit/ in a blog post] {{Webarchive|url=https://archive.today/20121209102341/http://blog.cdleary.com/2010/09/picing-on-javascript-for-fun-and-profit/ |date=9 December 2012 }}. More technical information can be found in other developer's blogs: [http://www.bailopan.net/blog/ dvander], [https://web.archive.org/web/20101211124954/http://blog.mozilla.com/dmandelin/ dmandelin].

===IonMonkey===
IonMonkey was a JavaScript JIT compiler of Mozilla, which was aimed to enable many new optimizations that were impossible with the prior JägerMonkey architecture.<ref name="mozilla1">{{cite web |url=https://wiki.mozilla.org/Platform/Features/IonMonkey |title=Platform/Features/IonMonkey - MozillaWiki |publisher=Wiki.mozilla.org |date=11 February 2013 |access-date=21 March 2013 |archive-url=https://web.archive.org/web/20130308142525/https://wiki.mozilla.org/Platform/Features/IonMonkey |archive-date=8 March 2013 |url-status=live |df=dmy-all }}</ref>

IonMonkey was a more traditional compiler: it translated SpiderMonkey [[bytecode]] into a [[control-flow graph]], using [[static single assignment form]] (SSA) for the [[intermediate representation]]. This architecture enabled well-known optimizations from other programming languages to be used for JavaScript, including type specialization, [[function inlining]], linear-scan [[register allocation]], [[dead code elimination]], and [[loop-invariant code motion]].<ref>{{cite web |url=http://www.infoq.com/news/2011/05/ionmonkey |title=IonMonkey: Mozilla's new JavaScript JIT compiler |publisher=Infoq.com |access-date=21 March 2013 |archive-url=https://web.archive.org/web/20121208010755/http://www.infoq.com/news/2011/05/ionmonkey |archive-date=8 December 2012 |url-status=live |df=dmy-all }}</ref>

The compiler can emit fast [[native code]] translations of JavaScript functions on the [[ARM architecture|ARM]], [[x86]], and [[x86-64]] platforms. It has been the default engine since Firefox 18.<ref>{{cite web |url=https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/18.0/releasenotes/ |title=Firefox Notes - Desktop |publisher=Mozilla.org |date=8 January 2013 |access-date=21 March 2013 |archive-url=https://web.archive.org/web/20140902235153/http://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/18.0/releasenotes/ |archive-date=2 September 2014 |url-status=live |df=dmy-all }}</ref>

===OdinMonkey===
OdinMonkey is the name of Mozilla's new optimization module for [[asm.js]], an easily compilable subset of JavaScript. OdinMonkey itself is not a JIT compiler, it uses the current JIT compiler. It's included with Firefox from release 22.

===WarpMonkey===
The WarpMonkey JIT replaces the former IonMonkey engine from version 83.<ref>{{Cite web|title=Warp: Improved JS performance in Firefox 83 – Mozilla Hacks - the Web developer blog|url=https://hacks.mozilla.org/2020/11/warp-improved-js-performance-in-firefox-83|date=13 November 2020|access-date=2021-08-28|website=Mozilla Hacks – the Web developer blog|language=en-US}}</ref> It is able to inline other scripts and specialize code based on the data and arguments being processed.
It translates the bytecode and Inline Cache data into a Mid-level [[Intermediate representation|Intermediate Representation]] (Ion MIR) representation. This graph is transformed and optimized before being lowered to a Low-level Intermediate Representation (Ion LIR). This LIR performs register allocation and then generates native machine code in a process called Code Generation.
The optimizations here assume that a script continues to see data similar what has been seen before. The Baseline JITs are essential to success here because they generate ICs that match observed data. If after a script is compiled with Warp, it encounters data that it is not prepared to handle it performs a bailout. The bailout mechanism reconstructs the native machine stack frame to match the layout used by the Baseline Interpreter and then branches to that interpreter as though we were running it all along. Building this stack frame may use special side-table saved by Warp to reconstruct values that are not otherwise available.<ref>{{Cite web|title=SpiderMonkey — Firefox Source Docs documentation|url=https://firefox-source-docs.mozilla.org/js/index.html|access-date=2021-08-28|website=firefox-source-docs.mozilla.org}}</ref>