Lançamento do V8 v9.3

A cada seis semanas, criamos um novo branch do V8 como parte do nosso processo de lançamento. Cada versão é ramificada a partir do branch principal do Git do V8 imediatamente antes de um marco beta do Chrome. Hoje estamos felizes em anunciar nosso mais novo branch, V8 versão 9.3, que está em beta até seu lançamento em coordenação com o Chrome 93 Stable em algumas semanas. O V8 v9.3 está repleto de muitas novidades voltadas para desenvolvedores. Este post oferece um preview de alguns destaques em antecipação ao lançamento.

JavaScript

Compilação em lote com Sparkplug

Lançamos nosso novo compilador JIT de médio nível e super rápido Sparkplug na versão v9.1. Por motivos de segurança, o V8 protege contra gravação a memória de código que gera, exigindo que altere as permissões entre gravável (durante a compilação) e executável. Isso é atualmente implementado usando chamadas mprotect. No entanto, como o Sparkplug gera código tão rapidamente, o custo de chamar mprotect para cada função compilada individual tornou-se um grande gargalo no tempo de compilação. No V8 v9.3, estamos introduzindo a compilação em lote para o Sparkplug: em vez de compilar cada função individualmente, compilamos várias funções em um lote. Isso amortiza o custo de alterar as permissões de página de memória fazendo isso apenas uma vez por lote.

A compilação em lote reduz o tempo geral de compilação (Ignition + Sparkplug) em até 44% sem regredir a execução do JavaScript. Se olharmos apenas para o custo de compilar o código Sparkplug, o impacto é obviamente maior, por exemplo, uma redução de 82% para o benchmark docs_scrolling (veja abaixo) no Windows 10. Surpreendentemente, a compilação em lote melhorou o desempenho de compilação ainda mais do que o custo de W^X, já que agrupar operações semelhantes geralmente é melhor para o CPU. No gráfico abaixo, você pode ver o impacto de W^X no tempo de compilação (Ignition + Sparkplug) e como a compilação em lote mitigou bem esse overhead.

Object.hasOwn

Object.hasOwn é um alias mais fácil de usar para Object.prototype.hasOwnProperty.call.

Por exemplo:

Object.hasOwn({ prop: 42 }, 'prop')
// → true

Detalhes ligeiramente mais (mas não muito!) estão disponíveis em nosso explicador de recursos.

Causa de erro

A partir da v9.3, os vários construtores embutidos de Error são estendidos para aceitar um objeto de opções com uma propriedade cause como segundo parâmetro. Se tal objeto de opções for passado, o valor da propriedade cause será instalado como uma propriedade própria na instância de Error. Isso fornece uma maneira padronizada de encadear erros.

Por exemplo:

const parentError = new Error('parent');
const error = new Error('parent', { cause: parentError });
console.log(error.cause === parentError);
// → true

Como de costume, veja nosso explicador de recursos mais detalhado.

Mitigações de código não confiável desativadas no Android

Três anos atrás, introduzimos um conjunto de mitigações de geração de código para defender contra ataques de Spectre. Sempre percebemos que isso era uma solução temporária que fornecia apenas proteção parcial contra ataques do Spectre. A única proteção eficaz é isolar os sites via Site Isolation. Site Isolation foi habilitado no Chrome em dispositivos desktop há algum tempo, no entanto, habilitar o Site Isolation completo no Android tem sido mais desafiador devido a restrições de recursos. Porém, a partir do Chrome 92, Site Isolation no Android foi habilitado em muitos mais sites que contêm dados sensíveis.

Assim, decidimos desativar as mitigações de geração de código do V8 para Spectre no Android. Essas mitigações são menos eficazes do que o Site Isolation e impõem um custo de desempenho. Desativá-las traz o Android para o mesmo nível das plataformas desktop, onde já foram desativadas desde a v7.0 do V8. Ao desativar essas mitigações, vimos algumas melhorias significativas no desempenho de benchmarks no Android.

API do V8

Por favor, use git log branch-heads/9.2..branch-heads/9.3 include/v8.h para obter uma lista das mudanças na API.