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.

Neste post, gostaríamos de apresentar o CodeStubAssembler (CSA), um componente do V8 que tem sido uma ferramenta muito útil para alcançar alguns grandes ganhos de desempenho nas últimas várias versões do V8. O CSA também melhorou significativamente a capacidade da equipe do V8 de otimizar rapidamente os recursos do JavaScript em um nível baixo com um alto grau de confiabilidade, o que aumentou a velocidade de desenvolvimento da equipe.

O desempenho do JavaScript sempre foi importante para a equipe do V8, e neste post gostaríamos de discutir um novo Benchmark de Ferramentas Web que temos usado recentemente para identificar e corrigir alguns gargalos de desempenho no V8. Você já pode estar ciente do forte compromisso do V8 com o Node.js, e este benchmark estende esse compromisso ao executar testes de desempenho especificamente baseados em ferramentas comuns de desenvolvedores construídas sobre Node.js. As ferramentas no Benchmark de Ferramentas Web são as mesmas usadas por desenvolvedores e designers hoje para criar sites modernos e aplicativos baseados em nuvem. Continuando nossos esforços contínuos para focar no desempenho do mundo real em vez de benchmarks artificiais, criamos o benchmark usando código real que os desenvolvedores executam diariamente.

A cada seis semanas, criamos um novo ramo do V8 como parte do nosso processo de lançamento. Cada versão é ramificada do Git master do V8 imediatamente antes de um marco Beta do Chrome. Hoje estamos felizes em anunciar nosso novo ramo, V8 versão 6.3, que estará em beta até seu lançamento em conjunto com o Chrome 63 Stable em algumas semanas. O V8 v6.3 está repleto de todos os tipos de benefícios voltados para desenvolvedores. Esta postagem fornece uma prévia de alguns dos destaques em antecipação ao lançamento.

Os proxies são parte integrante do JavaScript desde o ES2015. Eles permitem interceptar operações fundamentais em objetos e personalizar seu comportamento. Proxies formam uma parte central de projetos como jsdom e a biblioteca RPC Comlink. Recentemente, fizemos um grande esforço para melhorar o desempenho dos proxies no V8. Este artigo lança luz sobre padrões gerais de melhoria de desempenho no V8 e, em particular, para proxies.

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.

Em JavaScript, um objeto alocado escapa se ele for acessível fora da função atual. Normalmente, o V8 aloca novos objetos no heap do JavaScript, mas utilizando análise de escape, um compilador de otimização pode determinar quando um objeto pode ser tratado de forma especial porque seu tempo de vida está comprovadamente vinculado à ativação da função. Quando a referência a um objeto recém-alocado não escapa da função que o cria, os engines de JavaScript não precisam alocar explicitamente esse objeto no heap. Eles podem, em vez disso, tratar efetivamente os valores do objeto como variáveis locais da função. Isso, por sua vez, permite todos os tipos de otimizações, como armazenar esses valores na pilha ou em registradores, ou, em alguns casos, otimizar os valores completamente. Objetos que escapam (mais precisamente, objetos que não podem ser comprovadamente não escapantes) precisam ser alocados no heap.

Objetos JavaScript podem ter propriedades arbitrárias associadas a eles. Os nomes das propriedades dos objetos podem conter qualquer caractere. Um dos casos interessantes que um motor JavaScript pode escolher otimizar são propriedades cujos nomes são puramente numéricos, mais especificamente índices de array.

A cada seis semanas, criamos um novo branch do V8 como parte do nosso processo de lançamento. Cada versão é derivada do Git master do V8 imediatamente antes de uma etapa de Beta do Chrome. Hoje estamos satisfeitos em anunciar nosso mais novo branch, V8 versão 6.2, que está na versão beta até seu lançamento em coordenação com o Chrome 62 Stable em algumas semanas. O V8 v6.2 está repleto de vários recursos voltados para desenvolvedores. Este post fornece uma prévia de alguns dos destaques em antecipação ao lançamento.

Neste post do blog, gostaríamos de explicar como o V8 lida internamente com as propriedades do JavaScript. Do ponto de vista do JavaScript, são necessárias apenas algumas distinções para as propriedades. Objetos JavaScript se comportam principalmente como dicionários, com chaves de string e objetos arbitrários como valores. No entanto, a especificação trata propriedades indexadas por inteiros e outras propriedades de forma diferente durante a iteração. Fora isso, as diferentes propriedades se comportam praticamente da mesma maneira, independentemente de serem indexadas por inteiros ou não.