No V8 v9.1 desativamos temporariamente as funções internas incorporadas no desktop. Embora incorporar funções internas melhore significativamente o uso de memória, percebemos que chamadas de funções entre as funções internas incorporadas e o código compilado pelo JIT podem resultar em uma penalidade de desempenho considerável. Esse custo depende da microarquitetura do CPU. Neste post, vamos explicar por que isso está acontecendo, como o desempenho é afetado e o que planejamos fazer para resolver isso a longo prazo.

Fazer o JavaScript rodar rapidamente é essencial para um aplicativo web responsivo. Mesmo com as otimizações avançadas do V8, analisar e compilar JavaScript crítico durante a inicialização ainda pode criar gargalos de desempenho. Saber quais funções JavaScript compilar durante a compilação inicial do script pode acelerar o carregamento da página da web.

O compilador otimizador de última etapa do V8, o Turbofan, é conhecido como um dos poucos compiladores de produção em larga escala que utilizam Mar de Nós (SoN). No entanto, há quase três anos, começamos a nos livrar do Mar de Nós e a retornar para uma Representação Intermediária (IR) Gráfico de Fluxo de Controle (CFG) mais tradicional, que chamamos de Turboshaft. Até agora, todo o backend de JavaScript do Turbofan utiliza Turboshaft e o WebAssembly usa Turboshaft ao longo de todo o seu pipeline. Duas partes do Turbofan ainda usam algum Mar de Nós: o pipeline embutido, que estamos substituindo gradualmente pelo Turboshaft, e o frontend do pipeline de JavaScript, que estamos substituindo pelo Maglev, outro IR baseado em CFG. Este post no blog explica as razões que nos levaram a abandonar o Mar de Nós.

No V8, estamos constantemente buscando melhorar o desempenho do JavaScript. Como parte desse esforço, recentemente revisamos o conjunto de benchmarks JetStream2 para eliminar gargalos de desempenho. Este post detalha uma otimização específica que realizamos e que resultou em uma melhoria significativa de 2.5x no benchmark async-fs, contribuindo para um aumento perceptível na pontuação geral. A otimização foi inspirada pelo benchmark, mas padrões como esses aparecem em código do mundo real.

A API de Integração de Promises do JavaScript (JSPI) permite que aplicativos WebAssembly escritos presumindo acesso síncrono a funcionalidades externas operem sem problemas em um ambiente onde a funcionalidade é, na verdade, assíncrona.

A API de Integração de Promessas do JavaScript (JSPI) no WebAssembly tem uma nova API, disponível na versão M126 do Chrome. Falamos sobre o que mudou, como usá-la com o Emscripten e qual é o roteiro do JSPI.

JSPI é uma API que permite que aplicações WebAssembly que utilizam APIs sequenciais acessem APIs Web que são assíncronas. Muitas APIs Web são construídas em termos de objetos Promise do JavaScript: em vez de executar imediatamente a operação solicitada, elas retornam uma Promise para realizá-la. Por outro lado, muitas das aplicações compiladas para WebAssembly vêm do universo C/C++, que é dominado por APIs que bloqueiam o chamador até que sejam concluídas.

Após quase três anos desde o documento de design inicial e centenas de CLs no período, o Sandbox do V8 — um sandbox leve e em processo para o V8 — progrediu ao ponto em que não é mais considerado um recurso experimental de segurança. A partir de hoje, o Sandbox do V8 está incluído no Programa de Recompensa por Vulnerabilidades do Chrome (VRP). Embora ainda existam vários problemas a serem resolvidos antes que se torne uma barreira de segurança robusta, sua inclusão no VRP é um passo importante nessa direção. O Chrome 123 pode ser considerado uma espécie de versão "beta" para o sandbox. Este post de blog aproveita esta oportunidade para discutir a motivação por trás do sandbox, mostrar como ele impede que a corrupção de memória no V8 se espalhe dentro do processo host e, por fim, explicar por que ele é um passo necessário para a segurança de memória.

A API de Integração de Promessas em JavaScript (JSPI) do WebAssembly está entrando em um teste de origem, com o lançamento do Chrome M123. Isso significa que você pode testar se você e seus usuários podem se beneficiar dessa nova API.

JSPI é uma API que permite que código chamado sequencial – que foi compilado para WebAssembly – acesse APIs da Web que são assíncronas. Muitas APIs da Web são criadas em termos de Promises do JavaScript: ao invés de executar a operação solicitada imediatamente, elas retornam uma Promise para fazê-lo. Quando a ação é finalmente realizada, o sistema de tarefas do navegador invoca quaisquer callbacks com a Promise. JSPI se integra a essa arquitetura para permitir que um aplicativo WebAssembly seja suspenso quando a Promise é retornada e retomado quando a Promise é resolvida.

Você já se perguntou de onde vêm undefined, true e outros objetos principais do JavaScript? Esses objetos são os átomos de qualquer objeto definido por usuário e precisam estar presentes primeiro. O V8 os chama de raízes imutáveis e imovíveis e eles vivem em seu próprio heap – o heap somente leitura. Como eles são usados constantemente, o acesso rápido é crucial. E o que poderia ser mais rápido do que adivinhar corretamente seu endereço de memória em tempo de compilação?

Bem-vindo ao emocionante mundo do V8, onde velocidade não é apenas uma característica, mas um estilo de vida. Enquanto nos despedimos de 2023, é hora de celebrar as impressionantes realizações que o V8 alcançou este ano.

Através de otimizações inovadoras de desempenho, o V8 continua a expandir os limites do que é possível no cenário em constante evolução da Web. Introduzimos um novo compilador de nível intermediário e implementamos várias melhorias na infraestrutura do compilador de alto nível, no runtime e no coletor de lixo, o que resultou em ganhos significativos de velocidade em todos os aspectos.