6 postagens marcadas com "ferramentas"

Esta postagem no blog foi escrita por José Dapena Paz (Igalia), com contribuições de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) e Shu-yu Guo (Google).

Nesta postagem sobre snapshots do heap do V8, falarei sobre alguns problemas de desempenho encontrados por engenheiros da Bloomberg e como os corrigimos para tornar a análise de memória do JavaScript mais rápida do que nunca.

O problema​

Engenheiros da Bloomberg estavam trabalhando no diagnóstico de um vazamento de memória em uma aplicação JavaScript. A aplicação estava falhando com erros de Out-Of-Memory. Para a aplicação testada, o limite do heap do V8 foi configurado para cerca de 1400 MB. Normalmente, o coletor de lixo do V8 deveria ser capaz de manter o uso do heap abaixo desse limite, então as falhas indicavam que provavelmente havia um vazamento.

Os últimos três meses foram uma experiência de aprendizado incrível para mim, já que me juntei à equipe do V8 (Google Londres) como estagiária e tenho trabalhado em uma nova ferramenta chamada Indicium.

Este analisador de sistema é uma interface web unificada para rastrear, depurar e analisar padrões de como Inline Caches (ICs) e Maps são criados e modificados em aplicações reais.

O V8 já possui uma infraestrutura de rastreamento para ICs e Maps, que pode processar e analisar eventos de IC usando o IC Explorer e eventos de Map usando o Map Processor. No entanto, ferramentas anteriores não nos permitiam analisar mapas e ICs de forma holística, o que agora é possível com o analisador de sistema.

Introdução​

Graças ao trabalho recente no Chrome e Emscripten, agora você pode usar até 4GB de memória em aplicações WebAssembly. Isso é um aumento em relação ao limite anterior de 2GB. Pode parecer estranho que tenha havido um limite - afinal, nenhum trabalho foi necessário para permitir que as pessoas usassem 512MB ou 1GB de memória! - mas acontece que há algumas coisas especiais acontecendo no salto de 2GB para 4GB, tanto no navegador quanto na cadeia de ferramentas, que descreveremos neste post.

Temos um número crescente de compiladores e outras ferramentas que geram ou manipulam arquivos .wasm, e às vezes você pode querer dar uma olhada por dentro. Talvez você seja um desenvolvedor de tal ferramenta, ou, mais diretamente, um programador direcionado ao Wasm, e esteja se perguntando como é o código gerado, seja por motivo de desempenho ou outros.

O Emscripten sempre se concentrou em compilar primeiro para a Web e para outros ambientes JavaScript, como o Node.js. Mas à medida que o WebAssembly começa a ser usado sem JavaScript, novos casos de uso estão surgindo, e por isso estamos trabalhando no suporte para a emissão de arquivos Wasm autônomos no Emscripten, que não dependem do runtime JS do Emscripten! Este post explica por que isso é interessante.

WebAssembly é normalmente compilado a partir de uma linguagem fonte, o que significa que os desenvolvedores precisam de ferramentas para utilizá-lo. Por isso, a equipe V8 trabalha em projetos de código aberto relevantes como LLVM, Emscripten, Binaryen e WABT. Este post descreve parte do trabalho que realizamos no Emscripten e no LLVM, o que em breve permitirá que o Emscripten mude para o backend WebAssembly do LLVM por padrão — por favor, teste e relate quaisquer problemas!