36 publicaciones etiquetados con "internals"

Anteriormente, discutimos cómo los motores de JavaScript optimizan el acceso a objetos y arreglos mediante el uso de Shapes y Inline Caches, y exploramos cómo los motores aceleran el acceso a las propiedades de prototipo en particular. Este artículo describe cómo V8 elige representaciones en memoria óptimas para varios valores de JavaScript, y cómo eso impacta en la maquinaria de formas, todo lo cual ayuda a explicar un reciente límite de rendimiento en V8 en el núcleo de React.

Hay un dicho entre los desarrolladores que dice que el código más rápido es aquel que no se ejecuta. Del mismo modo, el código más rápido para compilar es aquel que no necesita ser compilado. El almacenamiento en caché de código de WebAssembly es una nueva optimización en Chrome y V8 que intenta evitar la compilación de código almacenando en caché el código nativo generado por el compilador. Hemos escrito sobre cómo Chrome y V8 almacenan en caché el código de JavaScript en el pasado, y sobre las mejores prácticas para aprovechar esta optimización. En esta publicación de blog, describimos el funcionamiento del almacenamiento en caché de código de WebAssembly en Chrome y cómo los desarrolladores pueden aprovecharlo para acelerar la carga de aplicaciones con módulos WebAssembly grandes.

El almacenamiento en caché de código (también conocido como almacenamiento en caché de bytecode) es una optimización importante en los navegadores. Reduce el tiempo de inicio de sitios web visitados frecuentemente almacenando en caché el resultado del análisis y la compilación. La mayoría de los navegadores populares implementan alguna forma de almacenamiento en caché de código, y Chrome no es una excepción. De hecho, hemos escrito, y hablado sobre cómo Chrome y V8 almacenan en caché el código compilado en el pasado.

Para ejecutar un programa de JavaScript, el texto fuente necesita ser procesado para que V8 pueda entenderlo. V8 comienza analizando el texto fuente en un árbol de sintaxis abstracta (AST), un conjunto de objetos que representan la estructura del programa. Ese AST se compila en bytecode mediante Ignition. El rendimiento de estas fases de análisis + compilación es importante: V8 no puede ejecutar código antes de que la compilación esté terminada. En esta serie de publicaciones en el blog, nos enfocamos en el análisis y el trabajo realizado en V8 para entregar un analizador extremadamente rápido.

V8 v7.4 ahora admite la ejecución de JavaScript sin asignar memoria ejecutable en tiempo de ejecución.

En su configuración predeterminada, V8 depende en gran medida de la capacidad de asignar y modificar memoria ejecutable en tiempo de ejecución. Por ejemplo, el compilador optimizador TurboFan crea código nativo para funciones de JavaScript (JS) calientes justo a tiempo, y la mayoría de las expresiones regulares de JS se compilan a código nativo por el motor irregexp. Crear memoria ejecutable en tiempo de ejecución es parte de lo que hace que V8 sea rápido.

En los últimos años, el recolector de basura (GC) de V8 ha cambiado mucho. El proyecto Orinoco ha transformado un recolector de basura secuencial que detenía completamente la ejecución en un recolector mayormente paralelo y concurrente con retroceso incremental.

Array.prototype.sort fue una de las últimas funciones integradas implementadas en JavaScript autohospedado en V8. Trasladarlo nos dio la oportunidad de experimentar con diferentes algoritmos y estrategias de implementación y finalmente hacerlo estable en V8 v7.0 / Chrome 70.

V8 v6.9 incluye Liftoff, un nuevo compilador base para WebAssembly. Liftoff ahora está habilitado de forma predeterminada en sistemas de escritorio. Este artículo detalla la motivación para agregar otro nivel de compilación y describe la implementación y el rendimiento de Liftoff.

Este artículo describe la técnica de recolección de basura llamada marcado concurrente. La optimización permite que una aplicación de JavaScript continúe ejecutándose mientras el recolector de basura escanea el montón para encontrar y marcar objetos vivos. Nuestros benchmarks muestran que el marcado concurrente reduce el tiempo dedicado al marcado en el hilo principal en un 60%–70%. El marcado concurrente es la última pieza del proyecto Orinoco — el proyecto para reemplazar incrementalmente el antiguo recolector de basura con el nuevo recolector de basura mayormente concurrente y paralelo. El marcado concurrente está habilitado por defecto en Chrome 64 y Node.js v10.