Un artículo reciente sobre Recolección de Basura en WebAssembly (WasmGC) explica, a un nivel alto, cómo la propuesta de Recolección de Basura (GC) tiene como objetivo brindar mejor soporte a los lenguajes con GC en Wasm, lo cual es muy importante dada su popularidad. En este artículo, profundizaremos en los detalles técnicos de cómo lenguajes con GC como Java, Kotlin, Dart, Python y C# pueden ser trasladados a Wasm. De hecho, existen dos enfoques principales:

La integridad del flujo de control (CFI) es una característica de seguridad que tiene como objetivo prevenir explotaciones que secuestren el flujo de control. La idea es que, incluso si un atacante logra corromper la memoria de un proceso, controles de integridad adicionales pueden evitar que ejecuten código arbitrario. En esta publicación de blog, queremos discutir nuestro trabajo para habilitar CFI en V8.

Esta publicación en el blog ha sido escrita por José Dapena Paz (Igalia), con contribuciones de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) y Shu-yu Guo (Google).

En esta publicación sobre instantáneas de montón de V8, hablaré sobre algunos problemas de rendimiento encontrados por ingenieros de Bloomberg, y cómo los solucionamos para que el análisis de memoria de JavaScript sea más rápido que nunca.

El problema​

Los ingenieros de Bloomberg estaban trabajando en diagnosticar una fuga de memoria en una aplicación de JavaScript. Estaba fallando con errores de Falta de Memoria. Para la aplicación probada, el límite del montón de V8 estaba configurado en aproximadamente 1400 MB. Normalmente, el colector de basura de V8 debería poder mantener el uso del montón por debajo de ese límite, por lo que los fallos indicaban que probablemente había una fuga.

¡Estamos implementando las llamadas en cola de WebAssembly en V8 v11.2! En esta publicación, ofrecemos una breve descripción de esta propuesta, demostramos un caso de uso interesante para las corrutinas en C++ con Emscripten y mostramos cómo maneja V8 las llamadas en cola internamente.

¿Qué es la optimización de llamadas en cola?​

Una llamada se encuentra en posición de cola si es la última instrucción ejecutada antes de regresar desde la función actual. Los compiladores pueden optimizar estas llamadas descartando el marco del llamador y reemplazando la llamada con un salto.

Esto es particularmente útil para las funciones recursivas. Por ejemplo, considere esta función en C que suma los elementos de una lista enlazada:

int sum(List* list, int acc) {
  if (list == nullptr) return acc;
  return sum(list->next, acc + list->val);
}

Con una llamada regular, esto consume un espacio de pila de 𝒪(n): cada elemento de la lista agrega un nuevo marco en la pila de llamadas. Con una lista lo suficientemente larga, esto podría desbordar rápidamente la pila. Al reemplazar la llamada con un salto, la optimización de llamadas en cola convierte efectivamente esta función recursiva en un bucle que utiliza un espacio de pila de 𝒪(1):

Es absolutamente idiota tener punteros de 64 bits cuando compilo un programa que usa menos de 4 gigabytes de RAM. Cuando tales valores de puntero aparecen dentro de una estructura, no solo desperdician la mitad de la memoria, sino que también efectivamente descartan la mitad de la caché.

– Donald Knuth (2008)

Históricamente, hubo una publicación de blog para cada nueva rama de lanzamiento de V8. Quizás hayas notado que no ha habido una publicación de blog de lanzamiento desde la versión 9.9. A partir de la versión 10.0, dejaremos de publicar blogs de lanzamientos para cada nueva rama. Pero no te preocupes, ¡toda la información que solías obtener a través de las publicaciones de blogs de lanzamientos sigue estando disponible! Sigue leyendo para saber dónde encontrar esa información en el futuro.

La seguridad de memoria en Chrome es un esfuerzo continuo para proteger a nuestros usuarios. Constantemente experimentamos con diferentes tecnologías para estar un paso adelante de los actores maliciosos. En este espíritu, esta publicación trata sobre nuestro camino usando tecnologías de análisis de heap para mejorar la seguridad de memoria de C++.

Los campos de clase se implementaron en V8 desde la versión v7.2 y los métodos privados de clase se implementaron desde la versión v8.4. Después de que las propuestas alcanzaran el estadio 4 en 2021, comenzó el trabajo para mejorar el soporte de las nuevas características de clase en V8; hasta entonces, había dos problemas principales que afectaban su adopción:

Cada cuatro semanas, creamos una nueva rama de V8 como parte de nuestro proceso de lanzamiento. Cada versión se origina desde el Git principal de V8 inmediatamente antes de un hito de Chrome Beta. Hoy nos complace anunciar nuestra nueva rama, V8 versión 9.9, que está en beta hasta su lanzamiento en coordinación con Chrome 99 Stable en varias semanas. V8 v9.9 está llena de novedades dirigidas a los desarrolladores. Esta publicación ofrece un adelanto de algunos de los aspectos destacados en anticipación al lanzamiento.

Aunque el título de esta publicación puede sugerir una inmersión profunda en una colección de libros sobre cárter de aceite – lo cual, considerando las normas de construcción para cárteres, es un tema sorprendentemente literario –, en su lugar vamos a mirar un poco más de cerca a Oilpan, un recolector de basura de C++ que se aloja a través de V8 como biblioteca desde la versión V8 v9.4.