Los objetos de JavaScript en V8 se asignan en un montón administrado por el recolector de basura de V8. En publicaciones anteriores del blog ya hemos hablado sobre cómo reducimos los tiempos de pausa de la recolección de basura (más de una vez) y el consumo de memoria. En esta publicación del blog presentamos el Scavenger paralelo, una de las características más recientes de Orinoco, el recolector de basura principalmente concurrente y paralelo de V8, y discutimos las decisiones de diseño y enfoques alternativos que implementamos en el camino.

En esta publicación queremos presentar el CodeStubAssembler (CSA), un componente en V8 que ha sido una herramienta muy útil para lograr algunos grandes mejoras de rendimiento en las últimas versiones de V8. El CSA también mejoró significativamente la capacidad del equipo de V8 para optimizar rápidamente las funciones de JavaScript a un nivel bajo con un alto grado de confiabilidad, lo que mejoró la velocidad de desarrollo del equipo.

El rendimiento de JavaScript siempre ha sido importante para el equipo de V8, y en esta publicación nos gustaría hablar sobre un nuevo Benchmark de Herramientas Web de JavaScript que hemos estado utilizando recientemente para identificar y corregir algunos cuellos de botella de rendimiento en V8. Probablemente ya estés al tanto del fuerte compromiso de V8 con Node.js, y este benchmark amplía ese compromiso al ejecutar específicamente pruebas de rendimiento basadas en herramientas comunes para desarrolladores construidas sobre Node.js. Las herramientas en el Benchmark de Herramientas Web son las mismas que los desarrolladores y diseñadores utilizan hoy en día para crear sitios web modernos y aplicaciones basadas en la nube. Continuando con nuestros esfuerzos en curso para centrarnos en el rendimiento en el mundo real en lugar de benchmarks artificiales, creamos el benchmark usando código real que los desarrolladores ejecutan a diario.

Cada seis semanas, creamos una nueva rama de V8 como parte de nuestro proceso de lanzamiento. Cada versión se deriva del Git master de V8 inmediatamente antes de un hito de Chrome Beta. Hoy nos complace anunciar nuestra rama más reciente, versión 6.3 de V8, que está en beta hasta su lanzamiento en coordinación con Chrome 63 Stable en varias semanas. V8 v6.3 está repleta de todo tipo de novedades para desarrolladores. Este post proporciona un adelanto de algunos de los aspectos destacados en anticipación al lanzamiento.

Los proxies han sido una parte integral de JavaScript desde ES2015. Permiten interceptar operaciones fundamentales en objetos y personalizar su comportamiento. Los proxies forman una parte esencial de proyectos como jsdom y la biblioteca Comlink RPC. Recientemente, hemos puesto mucho esfuerzo en mejorar el rendimiento de los proxies en V8. Este artículo aporta algo de luz sobre los patrones generales de mejora de rendimiento en V8 y en proxies en particular.

Hace aproximadamente tres meses, me uní al equipo de V8 (Google Munich) como pasante y desde entonces he estado trabajando en el Desoptimizador de la máquina virtual, algo completamente nuevo para mí que resultó ser un proyecto interesante y desafiante. La primera parte de mi pasantía se enfocó en mejorar la seguridad de la máquina virtual. La segunda parte se centró en mejoras de rendimiento, específicamente en la eliminación de una estructura de datos utilizada para la desvinculación de funciones previamente desoptimizadas, que representaba un cuello de botella de rendimiento durante la recolección de basura. Esta publicación describe esta segunda parte de mi pasantía. Explicaré cómo V8 solía desvincular funciones desoptimizadas, cómo cambiamos esto y qué mejoras de rendimiento se obtuvieron.

En JavaScript, un objeto asignado escapa si es accesible desde fuera de la función actual. Normalmente, V8 asigna nuevos objetos en el heap de JavaScript, pero utilizando el análisis de escape, un compilador optimizador puede identificar cuándo un objeto puede ser tratado de manera especial porque su tiempo de vida está demostrablemente limitado a la activación de la función. Cuando la referencia a un objeto recién asignado no escapa de la función que lo crea, los motores de JavaScript no necesitan asignar explícitamente ese objeto en el heap. En su lugar, pueden tratar los valores del objeto como variables locales de la función. Esto, a su vez, permite todo tipo de optimizaciones, como almacenar estos valores en la pila o en registros, o en algunos casos, eliminar los valores por completo. Los objetos que escapan (más precisamente, los objetos de los que no se puede demostrar que no escapan) deben ser asignados en el heap.

Los objetos en JavaScript pueden tener propiedades arbitrarias asociadas a ellos. Los nombres de las propiedades de los objetos pueden contener cualquier carácter. Uno de los casos interesantes que un motor de JavaScript puede elegir optimizar son las propiedades cuyos nombres son puramente numéricos, más específicamente índices de arrays.

Cada seis semanas, creamos una nueva rama de V8 como parte de nuestro proceso de lanzamiento. Cada versión se deriva del maestro de Git de V8 justo antes de un hito de Chrome Beta. Hoy nos complace anunciar nuestra rama más reciente, versión 6.2 de V8, que está en beta hasta su lanzamiento en coordinación con Chrome 62 Stable en varias semanas. V8 v6.2 está llena de todo tipo de cosas buenas para los desarrolladores. Esta publicación proporciona un avance de algunos de los puntos destacados en anticipación al lanzamiento.

En esta publicación de blog queremos explicar cómo V8 maneja las propiedades de JavaScript internamente. Desde el punto de vista de JavaScript, solo se necesitan unas pocas distinciones para las propiedades. Los objetos JavaScript se comportan principalmente como diccionarios, con claves de cadena y objetos arbitrarios como valores. Sin embargo, la especificación trata las propiedades con índices enteros y otras propiedades de manera diferente durante la iteración. Fuera de eso, las diferentes propiedades se comportan mayormente de la misma manera, independientemente de si tienen índices enteros o no.