Lo Que Todos Fingimos Saber: Las Diferencias Entre el Motor de JS y el Tiempo de Ejecución de JS

Hola a todos, bienvenidos a nuestra charla. Hoy vamos a hablar sobre lo que todos presentamos para conocer, la diferencia entre el motor de JavaScript y el tiempo de ejecución de JavaScript. Antes de comenzar, mi nombre es Sam y esta es mi co-presentadora, Karina. Ambos somos de Nueva York, ambos jugamos al tenis, ambos fuimos a la misma escuela secundaria, y ambos actualmente trabajamos en Bloomberg como ingenieros de software. Y hoy estamos realmente emocionados de hablar con ustedes sobre JavaScript. Antes de sumergirnos, ¿por qué estamos dando esta charla y por qué es relevante para ustedes? El desarrollo moderno de JavaScript está lleno de frameworks muy útiles que te permiten construir y enviar código muy rápidamente. Pero estos frameworks abstraen muchas de las complejidades de bajo nivel que hacen que tu código funcione. Creemos que entender lo que sucede bajo el capó te permitirá tener un modelo mental de cómo se está ejecutando tu código para que puedas escribir y depurar más fácilmente tu código JavaScript. JavaScript es técnicamente una especificación, eso es todo. ECMAScript es el nombre de la especificación para JavaScript y define qué es JavaScript. Entonces, ¿qué exactamente define ECMAScript? Define la sintaxis, los tipos disponibles, los operadores y la semántica del lenguaje. Puedes pensar en estos como las reglas para los caracteres que realmente escribes, como for, while, if, corchetes, y así sucesivamente. Además de ECMAScript, también está el motor del que hablará Karina, y ese motor implementa la especificación. Y luego está el tiempo de ejecución que toma el motor y te permite ejecutar tu código. Y ahora le paso la palabra a Karina.

Sí, así que echemos un vistazo más de cerca al motor. Los MDN web docs tienen una definición para los motores de JavaScript. En pocas palabras, son solo programas de bajo nivel que analizan y ejecutan código JavaScript. También convierten tu JavaScript de alto nivel en código máquina rápido que puede ser ejecutado por la CPU para algunos caminos de código. Y repasaremos cómo hace esto al observar primero cómo los componentes del motor procesan el código JavaScript.

Así que primero, tu código fuente de JavaScript se pasa al analizador. Este analiza ese código fuente y lo convierte en una representación en árbol del código fuente o el árbol de sintaxis abstracta. Luego, ese árbol se pasa al intérprete que lee y ejecuta instrucciones de bajo nivel específicas del motor llamadas código de bytes. JavaScript es un lenguaje dinámico, por lo que los tipos no se conocen hasta el tiempo de ejecución, y eso hace que sea difícil optimizar de antemano, a diferencia de lenguajes como C o C++.

Así que los intérpretes de JavaScript hacen un par de cosas. Una, ejecutan el código de bytes paso a paso. Pero mientras hacen eso, también recopilan información de tipos y datos de perfilado, que incluyen información como la frecuencia de llamadas a funciones, formas de argumentos, y cuando una función se llama con frecuencia, lo que llamamos una función caliente o un camino de código caliente, el motor lo identifica como digno de optimización. Así que el intérprete luego pasa esos datos de perfilado y ese código de bytes al compilador de optimización o al compilador justo a tiempo.

Y el compilador usará esa información para crear código máquina altamente optimizado para ser ejecutado directamente por la CPU. Y hay algunos métodos que el compilador emplea para generar este código máquina rápido. Utiliza especialización de tipos, que es básicamente generar código máquina adaptado a los tipos de datos reales utilizados en tiempo de ejecución. Utiliza inlining de funciones, donde reemplaza funciones pequeñas con sus cuerpos reales en el sitio de llamada, y también desenrollado de bucles.

Así que en lugar de ejecutar un bucle pequeño muchas veces, expandirá el cuerpo del bucle para hacer múltiples iteraciones. A medida que el compilador de optimización optimiza tu código, se basa en suposiciones basadas en cómo tu código se ha comportado hasta ahora. Así que podría ver que una variable es siempre un número, o podría notar que un objeto siempre tiene la misma estructura, y estos ayudan al motor a generar ese código máquina altamente eficiente y omitir comprobaciones en tiempo de ejecución. Sin embargo, si una suposición se rompe, ese código máquina optimizado se descarta y el código de bytes original es enviado de vuelta al intérprete.

Así que esto puede llevar tiempo, y las desoptimizaciones frecuentes debido a patrones de código inestables pueden añadir una sobrecarga significativa. Y hay un par de cosas que nosotros como desarrolladores podemos hacer para evitar que las suposiciones se rompan. Así que una suposición que tu motor hace es que las variables y los parámetros de función se usan consistentemente con los mismos tipos. Así que podemos asegurar la estabilidad de tipos manteniendo nuestras funciones monomórficas, y eso ayuda a tus motores a usar caches en línea para recordar la estructura de la función.

y eso ayuda a tus motores a usar caches en línea para recordar la estructura de la función. Así que queremos asegurarnos de que siempre usamos los mismos tipos de entrada. Otro ejemplo es usar arrays de tipo estable, o arrays donde todos los elementos son del mismo tipo, por ejemplo, números, y eso permite al motor usar representaciones internas especiales que se rompen cuando introduces un tipo mixto. Al motor también le encantan las formas de objetos consistentes. Asume que siguen la misma estructura interna y crean clases ocultas basadas en cosas como nombres de propiedades y orden de propiedades. Así que podemos evitar añadir propiedades después de la construcción del objeto. Añadir un atributo por sí solo no garantiza que romperá las suposiciones, depende en gran medida del contexto y si cambia la forma de la clase oculta, pero como regla general, quieres mantener las formas de los objetos consistentes. También quieres evitar los sitios de llamada megamórficos, que son llamadas a funciones o accesos a propiedades que usan diferentes tipos o formas en tiempo de ejecución. Queremos mantenerlo consistente porque los optimizadores no pueden inlining una función si no está claro qué versión se está llamando. Y al motor también le encanta cuando las funciones de código caliente son predecibles. Podemos ayudar a hacerlas predecibles evitando declaraciones de funciones en bucles para reducir la complejidad del alcance. Crear cierres repetidamente hace que el compilador just-in-time los trate como nuevos cada vez, y eso rompe la optimización. También podemos usar funciones puras, cortas y inlinables. Así que evita efectos secundarios y evita depender de o cambiar cualquier cosa fuera del alcance de la función para mantener las funciones puras. Así que en resumen, mantén tus funciones puras, cortas y de tipo estable, y usa herramientas como el nodo trace opt flag para monitorear lo que se está optimizando y desoptimizando para mejorar tu rendimiento.

Y de esa manera mantendrás a tu motor feliz y lo ayudarás a optimizar tu código. Ahora se lo pasaré de nuevo a Sam. Gracias, Karina. Así que vamos a adentrarnos un poco en el runtime. ¿Qué es el runtime? El runtime El runtime es solo código. Al igual que el motor es código de bajo nivel del que Karina acaba de hablar, el runtime también es código de bajo nivel. Es código que hace tres cosas principales. Inventa el motor, añade llamadas API adicionales para el entorno específico en el que estás ejecutando, y luego gestiona el event loop. Así que a la derecha, tenemos un ejemplo inventado de un runtime que vamos a repasar en cada uno de los pasos ahora mismo. Pero antes de comenzar, ¿cuáles son algunos runtimes ampliamente utilizados? Los dos más populares son Node, que es lo que usas para programar JavaScript en el back end, y luego está Browser, con el que todos estamos familiarizados. Cada navegador que probablemente hayas usado, Chrome, Firefox, Safari, tiene su propio runtime de JavaScript único. Entonces, ¿qué significa que un runtime embeba el motor? Si tomamos Node como ejemplo, Node es un runtime que está implementado en C++, y puedes ver a la derecha que está importando algo llamado V8. V8 es el motor que el runtime de Node usa, y V8 expone una API para embebido. Así que si fueras a hacer tu propio runtime con V8 como el motor, podrías importar eso y luego instanciarlo, y ahora tienes eso como el motor para tu runtime. Y el runtime también añade APIs. ¿Por qué necesitamos APIs en un runtime?

Cuando JavaScript se ejecuta en Node en un servidor back-end, necesita hacer cosas muy diferentes a lo que JavaScript necesitaría hacer si se ejecuta en el navegador en tu computadora, libre para acceder a un sitio web. Para hacer esto, es cuando el runtime implementa estas APIs, y para hacer eso, en tu código de bajo nivel, podrías definir una función, y luego después de eso, harías dos cosas. Definirías un binding, que te permite exponer esa función que escribes en C++, o C, u otro lenguaje de bajo nivel, y luego dos, después de definir el binding, puedes llamarlo en JavaScript. Así que hablamos de Node en el navegador. ¿Cuáles son algunas APIs comunes de runtime para Node? En Node, quieres poder acceder al sistema de archivos con FS, quieres obtener información a nivel de sistema como información de CPU o memoria, puedes hacerlo con la API de OS, y luego también quieres crear servicios usando HTTP y HTTPS. Si estás usando JavaScript en un navegador, y estás en un runtime de navegador, quieres hacer cosas muy diferentes. Quieres poder interactuar con HTML a través del DOM, quieres hacer solicitudes de red usando Fetch, y luego quieres almacenar cosas en tu navegador usando local storage y session storage. Hay muchos otros runtimes y motores. Esta no es una lista completa, pero algunos runtimes y motores que deberías conocer. Está Deno, Bun, y Electron, esos son runtimes, y luego para motores, está V8, está JavaScript Core, y luego está V8 Plus Chromium.

Hasta ahora, hemos cubierto las dos cosas que hace el runtime. La tercera cosa más importante, no la más importante, pero una cosa muy importante, es el event loop. ¿Qué es el event loop? Bueno, el runtime usa el event loop para determinar cuándo ejecutar tu código. El event loop es solo código adicional que es parte del runtime que escribes, y algunos event loops son incluso bibliotecas. Como Node usa la biblioteca liduv del event loop, que es una biblioteca de C++ que puedes embebir en tu propio código. Para entender lo que el event loop está haciendo, hay cuatro componentes que queremos tener en cuenta. Está el propio event loop, que es el código que está escrito en el runtime. Está la call stack, que es donde tu código se ejecuta realmente, y luego hay dos colas, la microtask queue y la task queue, que también se refiere como la macro task queue. Y todos estos se combinan con el runtime, el motor, y todos los otros componentes para ejecutar tu código. Así que a la derecha tenemos pseudocódigo que muestra lo que sucede a un alto nivel. Lo que está sucediendo es que el event loop verifica si la call stack está vacía. Si lo está, toma todo de la microtask queue y lo coloca en la call stack para que ese código sea ejecutado. Y luego, una vez que todos los elementos de la microtask queue están hechos, toma un elemento de la task queue o la macro task queue, lo pone en la call stack para ser ejecutado. Así que el event loop es un proceso que se ejecuta continuamente que puedes pensar que monitorea la call stack y la queue para decidir cuándo se ejecuta el código. Y esta es la forma principal en que JavaScript se comporta de manera asíncrona, aunque es de un solo hilo.

Así que para recapitular, el motor es un código de bajo nivel que ejecuta JavaScript. De manera similar al motor, el runtime también es código de bajo nivel y permite que tu código sea ejecutado. Gracias por escuchar nuestra charla.