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 es el nombre del nuevo módulo de optimización de Mozilla para asm.js , un subconjunto de JavaScript de fácil compilación. OdinMonkey no es un compilador JIT, sino que utiliza el compilador JIT actual. Está incluido en Firefox desde la versión 22. ^{[ 33 ]} OdinMonkey está deshabilitado por defecto desde Firefox 148, lanzado en febrero de 2026. ^{[ 34 ]}

El JIT de WarpMonkey reemplaza al antiguo motor IonMonkey de la versión 83. ^{[ 22 ]} Es capaz de insertar otros scripts y especializar el código según los datos y argumentos que se procesan. Traduce el bytecode y los datos de la caché en línea a una representación intermedia de nivel medio (Ion MIR). Este gráfico se transforma y optimiza antes de ser reducido a una representación intermedia de bajo nivel (Ion LIR). Esta LIR realiza la asignación de registros y luego genera código máquina nativo en un proceso llamado Generación de Código. Las optimizaciones aquí asumen que un script continúa viendo datos similares a los que ha visto antes. Los JIT de Baseline son esenciales para el éxito aquí porque generan IC que coinciden con los datos observados. Si después de compilar un script con Warp, encuentra datos que no está preparado para manejar, realiza un rescate. El mecanismo de rescate reconstruye el marco de pila de la máquina nativa para que coincida con el diseño utilizado por el intérprete de Baseline y luego se ramifica a ese intérprete como si lo estuviéramos ejecutando todo el tiempo. La construcción de este marco de pila puede utilizar una tabla lateral especial guardada por Warp para reconstruir valores que de otro modo no estarían disponibles. ^{[ 35 ]}