Array.prototype.sort estava entre os últimos recursos incorporados em JavaScript auto-hospedado no V8. Portá-lo ofereceu-nos a oportunidade de experimentar diferentes algoritmos e estratégias de implementação e finalmente torná-lo estável no V8 v7.0 / Chrome 70.
As funções embutidas do V8 (builtins) consomem memória em cada instância do V8. A contagem de builtins, o tamanho médio e o número de instâncias do V8 por aba do navegador Chrome aumentaram significativamente. Este post descreve como reduzimos o tamanho mediano do heap do V8 por site em 19% no último ano.
Este post descreve a técnica de coleta de lixo chamada marcação concorrente. A otimização permite que uma aplicação JavaScript continue a execução enquanto o coletor de lixo escaneia o heap para encontrar e marcar objetos vivos. Nossos benchmarks mostram que a marcação concorrente reduz o tempo gasto marcando na thread principal em 60%–70%. A marcação concorrente é a última peça do projeto Orinoco — o projeto para substituir incrementalmente o antigo coletor de lixo pelo novo coletor de lixo principalmente concorrente e paralelo. A marcação concorrente está habilitada por padrão no Chrome 64 e Node.js v10.
O V8 usa armazenamento em cache de código para guardar o código gerado de scripts usados frequentemente. A partir do Chrome 66, estamos armazenando mais código em cache ao gerar o cache após a execução de alto nível. Isso resulta em uma redução de 20–40% no tempo de análise e compilação durante o carregamento inicial.
Os objetos JavaScript no V8 são alocados em um heap gerenciado pelo coletor de lixo do V8. Em postagens anteriores no blog, já falamos sobre como reduzir os tempos de pausa na coleta de lixo (mais de uma vez) e o consumo de memória. Nesta postagem, apresentamos o Scavenger paralelo, um dos últimos recursos do Orinoco, o coletor de lixo majoritariamente concorrente e paralelo do V8, e discutimos decisões de design e abordagens alternativas que implementamos ao longo do caminho.
Há cerca de três meses, me juntei à equipe V8 (Google Munique) como estagiária e, desde então, tenho trabalhado no Desotimizador da máquina virtual — algo completamente novo para mim, que se revelou um projeto interessante e desafiador. A primeira parte do meu estágio focou em melhorar a segurança da máquina virtual. A segunda parte focou em melhorias de desempenho, especificamente na remoção de uma estrutura de dados usada para desvincular funções previamente desotimizadas, que era um gargalo de desempenho durante a coleta de lixo. Este post descreve essa segunda parte do meu estágio. Vou explicar como o V8 costumava desvincular funções desotimizadas, como mudamos isso e quais foram as melhorias de desempenho obtidas.
Hoje estamos entusiasmados em anunciar o lançamento de um novo pipeline de execução JavaScript para o V8 v5.9 que chegará ao Chrome Stable na versão 59. Com o novo pipeline, alcançamos grandes melhorias de desempenho e economias significativas de memória em aplicativos JavaScript do mundo real. Discutiremos os números com mais detalhes no final deste post, mas primeiro vamos dar uma olhada no próprio pipeline.
A equipe do V8 está atualmente trabalhando em um novo pipeline de compiladores padrão que nos ajudará a trazer melhorias de velocidade para o JavaScript do mundo real. Você pode pré-visualizar o novo pipeline no Chrome Canary hoje para nos ajudar a verificar que não haverá surpresas quando implantarmos a nova configuração para todos os canais do Chrome.
Este post no blog aborda a recente migração das funções integradas de RegExp do V8 de uma implementação de JavaScript autônoma para uma que se conecta diretamente à nossa nova arquitetura de geração de código baseada no TurboFan.
Em um post anterior do blog, apresentamos o problema da queda de desempenho causada pela coleta de lixo que interrompe uma experiência de navegação fluida. Neste post do blog, introduzimos três otimizações que estabelecem as bases para um novo coletor de lixo no V8, codinome Orinoco. Orinoco é baseado na ideia de que implementar um coletor de lixo principalmente paralelo e simultâneo, sem limites geracionais rígidos, reduzirá a queda de desempenho na coleta de lixo e o consumo de memória enquanto fornece alta produtividade. Em vez de implementar Orinoco por trás de uma opção como um coletor de lixo separado, decidimos lançar os recursos do Orinoco incrementalmente no V8 diretamente a partir da árvore principal para beneficiar os usuários imediatamente. Os três recursos discutidos neste post são compactação paralela, processamento paralelo de conjunto registrado e alocação preta.