No Chrome M117 introduzimos um novo compilador otimizador: Maglev. Maglev está entre nossos compiladores existentes Sparkplug e TurboFan, e desempenha o papel de um compilador otimizador rápido que gera código suficientemente bom de forma rápida.

Até 2021, o V8 tinha dois principais níveis de execução: Ignition, o interpretador; e TurboFan, o compilador otimizador do V8 focado no desempenho máximo. Todo código JavaScript é primeiro compilado para bytecode do Ignition e executado interpretando-o. Durante a execução, o V8 rastreia como o programa se comporta, incluindo o monitoramento dos formatos e tipos de objetos. Tanto os metadados de execução em tempo de execução quanto o bytecode são usados pelo compilador otimizador para gerar código de máquina de alto desempenho, frequentemente especulativo, que é executado significativamente mais rápido do que o interpretador.

Um artigo recente sobre Coleta de Lixo em WebAssembly (WasmGC) explica, em alto nível, como a proposta de Coleta de Lixo (GC) visa oferecer melhor suporte às linguagens GC no Wasm, o que é muito importante dada sua popularidade. Neste artigo, discutiremos os detalhes técnicos de como linguagens GC como Java, Kotlin, Dart, Python e C# podem ser portadas para Wasm. De fato, existem duas abordagens principais:

A integridade do fluxo de controle (CFI) é uma funcionalidade de segurança que visa impedir que explorações assumam o controle do fluxo de controle. A ideia é que, mesmo que um invasor consiga corromper a memória de um processo, verificações adicionais de integridade podem impedir que executem código arbitrário. Neste post no blog, queremos discutir nosso trabalho para habilitar o CFI no V8.

Esta postagem no blog foi escrita por José Dapena Paz (Igalia), com contribuições de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) e Shu-yu Guo (Google).

Nesta postagem sobre snapshots do heap do V8, falarei sobre alguns problemas de desempenho encontrados por engenheiros da Bloomberg e como os corrigimos para tornar a análise de memória do JavaScript mais rápida do que nunca.

O problema​

Engenheiros da Bloomberg estavam trabalhando no diagnóstico de um vazamento de memória em uma aplicação JavaScript. A aplicação estava falhando com erros de Out-Of-Memory. Para a aplicação testada, o limite do heap do V8 foi configurado para cerca de 1400 MB. Normalmente, o coletor de lixo do V8 deveria ser capaz de manter o uso do heap abaixo desse limite, então as falhas indicavam que provavelmente havia um vazamento.

Estamos implementando chamadas em cauda no WebAssembly no V8 v11.2! Neste post, fornecemos uma breve visão geral dessa proposta, demonstramos um caso de uso interessante para corrotinas em C++ com Emscripten e mostramos como o V8 lida com chamadas em cauda internamente.

O que é Otimização de Chamadas em Cauda?​

Uma chamada está em posição de cauda se for a última instrução executada antes de retornar da função atual. Compiladores podem otimizar tais chamadas descartando o quadro do chamador e substituindo a chamada por um salto.

Isso é especialmente útil para funções recursivas. Por exemplo, considere esta função em C que soma os elementos de uma lista encadeada:

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

Com uma chamada regular, isso consome espaço em pilha 𝒪(n): cada elemento da lista adiciona um novo quadro na pilha de chamadas. Com uma lista suficientemente longa, isso pode estourar rapidamente a pilha. Substituindo a chamada por um salto, a otimização de chamadas em cauda efetivamente transforma esta função recursiva em um laço que usa espaço em pilha 𝒪(1):

É absolutamente idiota ter ponteiros de 64 bits quando eu compilo um programa que utiliza menos de 4 gigabytes de RAM. Quando esses valores de ponteiros aparecem dentro de uma estrutura, eles não apenas desperdiçam metade da memória, mas também efetivamente descartam metade do cache.

– Donald Knuth (2008)

Historicamente, houve uma postagem no blog para cada novo ramo de lançamento do V8. Você pode ter notado que não houve uma postagem de blog de lançamento desde o v9.9. A partir do v10.0, estamos descontinuando as postagens de blog de lançamento para cada novo ramo. Mas não se preocupe, todas as informações que você estava acostumado a receber através das postagens de blog de lançamento ainda estão disponíveis! Continue lendo para ver onde encontrar essas informações daqui para frente.

Segurança da memória no Chrome é um esforço contínuo para proteger nossos usuários. Estamos constantemente experimentando diferentes tecnologias para nos manter à frente de agentes maliciosos. Sob esse espírito, esta publicação fala sobre nossa jornada no uso de tecnologias de varredura de heap para melhorar a segurança de memória no C++.

Os campos de classe foram introduzidos no V8 desde a versão v7.2 e os métodos privados de classe foram incluídos desde a versão v8.4. Após as propostas alcançarem o estágio 4 em 2021, começou o trabalho de aprimorar o suporte aos novos recursos de classe no V8 - até então, havia dois principais problemas que impactavam sua adoção:

A cada quatro semanas, criamos um novo branch do V8 como parte de nosso processo de lançamento. Cada versão é derivada do Git principal do V8 imediatamente antes de um marco Beta do Chrome. Hoje, estamos felizes em anunciar nosso mais novo branch, V8 versão 9.9, que estará em fase beta até seu lançamento em coordenação com o Chrome 99 Stable em algumas semanas. O V8 v9.9 está cheio de novidades voltadas para os desenvolvedores. Este post fornece uma prévia de alguns destaques em antecipação ao lançamento.