Hacer que JavaScript funcione rápidamente es clave para una aplicación web receptiva. Incluso con las optimizaciones avanzadas de V8, analizar y compilar JavaScript crítico durante el inicio aún puede generar cuellos de botella en el rendimiento. Saber qué funciones de JavaScript compilar durante la compilación inicial del script puede acelerar la carga de las páginas web.
El compilador optimizador de última etapa de V8, Turbofan, es conocido por ser uno de los pocos compiladores de producción a gran escala que utiliza Sea of Nodes (SoN). Sin embargo, desde hace casi 3 años, hemos comenzado a deshacernos del Mar de Nodos y a recurrir a una Representación Intermedia (IR) más tradicional basada en Graphos de Flujo de Control (CFG), que hemos denominado Turboshaft. Hasta ahora, todo el backend de JavaScript de Turbofan usa Turboshaft en su lugar, y WebAssembly usa Turboshaft en toda su tubería. Dos partes de Turbofan aún usan algo del Mar de Nodos: la tubería integrada, que estamos reemplazando lentamente por Turboshaft, y el frontend de la tubería de JavaScript, que estamos reemplazando por Maglev, otra IR basada en CFG. Esta publicación en el blog explica las razones que nos llevaron a alejarnos del Mar de Nodos.
En V8, siempre estamos buscando mejorar el rendimiento de JavaScript. Como parte de este esfuerzo, recientemente volvimos a analizar el conjunto de pruebas de JetStream2 para eliminar caídas de rendimiento. Esta publicación detalla una optimización específica que realizamos y que generó una mejora significativa de 2.5x en la prueba de referencia async-fs, contribuyendo a un aumento notable en la puntuación general. La optimización se inspiró en el benchmark, pero este tipo de patrones también aparecen en código del mundo real.
La API de Integración de Promesas de JavaScript (JSPI) permite que las aplicaciones WebAssembly escritas bajo la suposición de acceso sincrónico a la funcionalidad externa operen sin problemas en un entorno en el que la funcionalidad es asíncrona.
La API de Integración de Promesas de JavaScript (JSPI) para WebAssembly tiene una nueva API, disponible en la versión M126 de Chrome. Hablamos sobre lo que ha cambiado, cómo usarla con Emscripten y cuál es la hoja de ruta para JSPI.
JSPI es una API que permite a las aplicaciones de WebAssembly que usan APIs secuenciales acceder a APIs web que son asíncronas. Muchas APIs web están diseñadas en términos de objetos Promise de JavaScript: en lugar de realizar inmediatamente la operación solicitada, devuelven un Promise para hacerlo. Por otro lado, muchas aplicaciones compiladas a WebAssembly provienen del universo C/C++, dominado por APIs que bloquean al llamador hasta que se completan.
Después de casi tres años desde el documento de diseño inicial y cientos de CLs en el ínterin, el Sandbox de V8 — un sandbox ligero dentro del proceso para V8 — ha avanzado hasta el punto en que ya no se considera una característica experimental de seguridad. A partir de hoy, el Sandbox de V8 está incluido en el Programa de Recompensas de Vulnerabilidades de Chrome (VRP). Si bien todavía hay varios problemas por resolver antes de que se convierta en un límite de seguridad fuerte, la inclusión en el VRP es un paso importante en esa dirección. Por lo tanto, Chrome 123 podría considerarse una especie de versión "beta" para el sandbox. Este artículo del blog aprovecha esta oportunidad para discutir la motivación detrás del sandbox, mostrar cómo evita que la corrupción de memoria en V8 se propague dentro del proceso anfitrión y, en última instancia, explicar por qué es un paso necesario hacia la seguridad de la memoria.
La API de Integración de Promesas JavaScript (JSPI) de WebAssembly está entrando en una prueba de origen con la versión M123 de Chrome. Lo que significa esto es que puedes probar si tú y tus usuarios pueden beneficiarse de esta nueva API.
JSPI es una API que permite que el llamado código secuencial —que ha sido compilado a WebAssembly— acceda a APIs web que son asíncronas. Muchas APIs web están diseñadas en términos de Promises de JavaScript: en lugar de realizar de inmediato la operación solicitada, devuelven un Promise para hacerlo. Cuando la acción finalmente se ejecuta, el administrador de tareas del navegador invoca cualquier callback con el Promise. JSPI se integra en esta arquitectura para permitir que una aplicación WebAssembly se suspenda cuando se devuelve el Promise y se reanude cuando el Promise se resuelve.
¿Alguna vez te has preguntado de dónde provienen undefined, true y otros objetos centrales de JavaScript? Estos objetos son los átomos de cualquier objeto definido por el usuario y necesitan estar ahí primero. V8 los llama raíces inmutables inamovibles y viven en su propio montón: el montón de solo lectura. Dado que se utilizan constantemente, el acceso rápido es crucial. ¿Y qué podría ser más rápido que adivinar correctamente su dirección de memoria en tiempo de compilación?
Bienvenido al emocionante mundo de V8, donde la velocidad no es solo una característica, sino un estilo de vida. Al despedirnos de 2023, es hora de celebrar los impresionantes logros que V8 ha alcanzado este año.
A través de innovadoras optimizaciones de rendimiento, V8 continúa ampliando los límites de lo que es posible en el paisaje en constante evolución de la Web. Hemos introducido un nuevo compilador de nivel intermedio y hemos implementado varias mejoras en la infraestructura del compilador de nivel superior, el tiempo de ejecución y el recolector de basura, lo que ha resultado en importantes ganancias de velocidad en general.
En Chrome M117 presentamos un nuevo compilador de optimización: Maglev. Maglev se sitúa entre nuestros compiladores existentes Sparkplug y TurboFan, y cumple el rol de un compilador de optimización rápida que genera un código suficientemente bueno, lo suficientemente rápido.
Hasta 2021, V8 tenía dos niveles principales de ejecución: Ignition, el intérprete; y TurboFan, el compilador de optimización de V8 enfocado en el rendimiento máximo. Todo el código JavaScript se compila primero en bytecode de Ignition y se ejecuta interpretándolo. Durante la ejecución, V8 rastrea cómo se comporta el programa, incluyendo el seguimiento de formas y tipos de objetos. Tanto los metadatos de ejecución en tiempo de ejecución como el bytecode se ingresan en el compilador de optimización para generar código máquina de alto rendimiento, a menudo especulativo, que se ejecuta significativamente más rápido que el intérprete.