23 postagens marcadas com "internos"

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.

A partir da versão 8.8, o V8 inclui um novo mecanismo experimental de RegExp sem retrocesso (além do já existente mecanismo Irregexp) que garante execução em tempo linear em relação ao tamanho da string de entrada. O mecanismo experimental está disponível por trás dos sinalizadores de funcionalidade mencionados abaixo.

Há uma batalha constante entre memória e desempenho. Como usuários, gostaríamos que as coisas fossem rápidas e consumissem o menor espaço de memória possível. Infelizmente, normalmente melhorar o desempenho tem um custo no consumo de memória (e vice-versa).

No final de 2018, começamos um projeto chamado V8 Lite, com o objetivo de reduzir drasticamente o uso de memória do V8. Inicialmente, este projeto foi concebido como um modo Lite separado do V8, focado especificamente em dispositivos móveis com pouca memória ou em cenários de uso que priorizam uma menor utilização de memória em vez da velocidade de execução. No entanto, durante o desenvolvimento, percebemos que muitas das otimizações de memória feitas para este modo Lite poderiam ser implementadas no V8 regular, beneficiando todos os seus usuários.

Anteriormente, discutimos como os motores de JavaScript otimizam o acesso a objetos e arrays por meio do uso de Shapes e Inline Caches, e exploramos como os motores aceleram o acesso a propriedades do protótipo em particular. Este artigo descreve como o V8 escolhe representações otimizadas na memória para vários valores JavaScript e como isso afeta a máquina de formas — tudo isso ajuda a explicar um recente declínio de desempenho no núcleo do React.

Existe um ditado entre os desenvolvedores de que o código mais rápido é o código que não roda. Da mesma forma, o código mais rápido para compilar é o código que não precisa ser compilado. O cacheamento de código WebAssembly é uma nova otimização no Chrome e no V8 que tenta evitar a compilação de código armazenando o código nativo produzido pelo compilador. Já escrevemos anteriormente sobre como o Chrome e o V8 armazenam em cache o código JavaScript e as melhores práticas para aproveitar essa otimização. Neste post, descrevemos o funcionamento do cache de código WebAssembly do Chrome e como os desenvolvedores podem usá-lo para acelerar o carregamento de aplicativos com grandes módulos WebAssembly.

O cache de código (também conhecido como cache de bytecode) é uma otimização importante nos navegadores. Ele reduz o tempo de inicialização de websites frequentemente visitados ao armazenar o resultado da análise e compilação. A maioria dos navegadores populares implementa alguma forma de cache de código, e o Chrome não é exceção. Na verdade, nós já escrevemos, e falamos sobre como o Chrome e o V8 armazenam em cache o código compilado no passado.

Para executar um programa JavaScript, o texto-fonte precisa ser processado para que o V8 possa entendê-lo. O V8 começa analisando o texto-fonte em uma árvore de sintaxe abstrata (AST), um conjunto de objetos que representam a estrutura do programa. Essa AST é compilada em bytecode pelo Ignition. O desempenho dessas fases de análise + compilação é importante: o V8 não pode executar o código antes que a compilação esteja concluída. Nesta série de posts de blog, focamos na análise e no trabalho feito no V8 para entregar um analisador extremamente rápido.

O V8 v7.4 agora suporta execução de JavaScript sem alocar memória executável em tempo de execução.

Na sua configuração padrão, o V8 depende muito da capacidade de alocar e modificar memória executável em tempo de execução. Por exemplo, o compilador otimizador TurboFan cria código nativo para funções JavaScript (JS) em tempo de execução, e a maioria das expressões regulares de JS são compiladas em código nativo pelo motor irregexp. Criar memória executável em tempo de execução é parte do que torna o V8 rápido.