Mono araña

TraceMonkey ^{[ 17 ]} fue el primer compilador JIT escrito para el lenguaje JavaScript. Inicialmente introducido como una opción en una versión beta y presentado en el blog de Brendan Eich el 23 de agosto de 2008, ^{[ 25 ]} el compilador pasó a formar parte de la versión principal como parte de SpiderMonkey en Firefox 3.5 , proporcionando "mejoras de rendimiento que van entre 20 y 40 veces más rápido" que el intérprete base en Firefox 3. ^{[ 26 ]}

En lugar de compilar funciones completas, TraceMonkey era un compilador JIT de rastreo , que opera registrando el flujo de control y los tipos de datos durante la ejecución del intérprete. Estos datos luego servían de base para la construcción de árboles de rastreo , rutas altamente especializadas del código nativo .

Las mejoras en JägerMonkey acabaron dejando obsoleto a TraceMonkey, especialmente con el desarrollo del motor de inferencia de tipos SpiderMonkey . TraceMonkey no está presente en SpiderMonkey desde Firefox 11 en adelante. ^{[ 27 ]}

JägerMonkey, conocido internamente como MethodJIT, era un compilador JIT de método completo diseñado para mejorar el rendimiento en casos donde TraceMonkey no podía generar código nativo estable . ^{[ 28 ] [ 29 ]} Se lanzó por primera vez en Firefox 4 y finalmente reemplazó por completo a TraceMonkey. A su vez, fue reemplazado por IonMonkey.

JägerMonkey funcionaba de forma muy diferente a otros compiladores de su clase: mientras que los compiladores típicos construían y optimizaban un grafo de flujo de control que representaba la función, JägerMonkey, en cambio, iteraba linealmente hacia adelante a través del bytecode de SpiderMonkey , la representación interna de la función. Si bien esto impide las optimizaciones que requieren la reordenación de instrucciones, la compilación con JägerMonkey tiene la ventaja de ser muy rápida, lo cual es útil para JavaScript, ya que la recompilación debido a cambios en los tipos de variables es frecuente.

Mozilla implementó una serie de optimizaciones críticas en JägerMonkey, entre las que destacan las cachés en línea polimórficas y la inferencia de tipos . ^{[ 30 ]}

La diferencia entre las técnicas JIT de TraceMonkey y JägerMonkey, así como la necesidad de ambas, se explicaron en un artículo de hacks.mozilla.org . Chris Leary, uno de los desarrolladores de SpiderMonkey, ofreció una explicación más detallada de los aspectos técnicos en una entrada de blog ( enlace obsoleto archivado el 9 de diciembre de 2012 en archive.today ). Se puede encontrar más información técnica en los blogs de otros desarrolladores: dvander y dmandelin .

IonMonkey era un compilador JIT de JavaScript de Mozilla, que tenía como objetivo permitir muchas optimizaciones nuevas que eran imposibles con la arquitectura anterior de JägerMonkey. ^{[ 31 ]}

IonMonkey era un compilador más tradicional: traducía el código de bytes de SpiderMonkey a un grafo de flujo de control , utilizando la forma de asignación única estática (SSA) para la representación intermedia . Esta arquitectura permitió utilizar optimizaciones bien conocidas de otros lenguajes de programación para JavaScript, incluyendo la especialización de tipos, la inserción de funciones en línea, la asignación de registros de exploración lineal , la eliminación de código muerto y el movimiento de código invariante en bucles . ^{[ 32 ]}

El compilador puede generar traducciones rápidas de código nativo de funciones JavaScript en las plataformas ARM , x86 y x86-64 . Ha sido el motor predeterminado desde Firefox 18. ^{[ 19 ]}

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.^[33] OdinMonkey is disabled by default since Firefox 148 released in February 2026.^[34]

The WarpMonkey JIT replaces the former IonMonkey engine from version 83.^[22] 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 (Ion MIR). 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.^[35]