A API de Integração de Promises do JavaScript (JSPI) permite que aplicativos WebAssembly escritos presumindo acesso síncrono a funcionalidades externas operem sem problemas em um ambiente onde a funcionalidade é, na verdade, assíncrona.
A API de Integração de Promessas do JavaScript (JSPI) no WebAssembly tem uma nova API, disponível na versão M126 do Chrome. Falamos sobre o que mudou, como usá-la com o Emscripten e qual é o roteiro do JSPI.
JSPI é uma API que permite que aplicações WebAssembly que utilizam APIs sequenciais acessem APIs Web que são assíncronas. Muitas APIs Web são construídas em termos de objetos Promise do JavaScript: em vez de executar imediatamente a operação solicitada, elas retornam uma Promise para realizá-la. Por outro lado, muitas das aplicações compiladas para WebAssembly vêm do universo C/C++, que é dominado por APIs que bloqueiam o chamador até que sejam concluídas.
A API de Integração de Promessas em JavaScript (JSPI) do WebAssembly está entrando em um teste de origem, com o lançamento do Chrome M123. Isso significa que você pode testar se você e seus usuários podem se beneficiar dessa nova API.
JSPI é uma API que permite que código chamado sequencial – que foi compilado para WebAssembly – acesse APIs da Web que são assíncronas. Muitas APIs da Web são criadas em termos de Promises do JavaScript: ao invés de executar a operação solicitada imediatamente, elas retornam uma Promise para fazê-lo. Quando a ação é finalmente realizada, o sistema de tarefas do navegador invoca quaisquer callbacks com a Promise. JSPI se integra a essa arquitetura para permitir que um aplicativo WebAssembly seja suspenso quando a Promise é retornada e retomado quando a Promise é resolvida.
Bem-vindo ao emocionante mundo do V8, onde velocidade não é apenas uma característica, mas um estilo de vida. Enquanto nos despedimos de 2023, é hora de celebrar as impressionantes realizações que o V8 alcançou este ano.
Através de otimizações inovadoras de desempenho, o V8 continua a expandir os limites do que é possível no cenário em constante evolução da Web. Introduzimos um novo compilador de nível intermediário e implementamos várias melhorias na infraestrutura do compilador de alto nível, no runtime e no coletor de lixo, o que resultou em ganhos significativos de velocidade em todos os aspectos.
Um artigo recente sobre Coleta de Lixo em WebAssembly (WasmGC) explica, em alto nível, como a proposta de Coleta de Lixo (GC) visa oferecer melhor suporte às linguagens GC no Wasm, o que é muito importante dada sua popularidade. Neste artigo, discutiremos os detalhes técnicos de como linguagens GC como Java, Kotlin, Dart, Python e C# podem ser portadas para Wasm. De fato, existem duas abordagens principais:
Estamos implementando chamadas em cauda no WebAssembly no V8 v11.2! Neste post, fornecemos uma breve visão geral dessa proposta, demonstramos um caso de uso interessante para corrotinas em C++ com Emscripten e mostramos como o V8 lida com chamadas em cauda internamente.
Uma chamada está em posição de cauda se for a última instrução executada antes de retornar da função atual. Compiladores podem otimizar tais chamadas descartando o quadro do chamador e substituindo a chamada por um salto.
Isso é especialmente útil para funções recursivas. Por exemplo, considere esta função em C que soma os elementos de uma lista encadeada:
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
Com uma chamada regular, isso consome espaço em pilha 𝒪(n): cada elemento da lista adiciona um novo quadro na pilha de chamadas. Com uma lista suficientemente longa, isso pode estourar rapidamente a pilha. Substituindo a chamada por um salto, a otimização de chamadas em cauda efetivamente transforma esta função recursiva em um laço que usa espaço em pilha 𝒪(1):
O V8 tem dois compiladores para compilar código WebAssembly em código de máquina que pode então ser executado: o compilador padrão Liftoff e o compilador otimizador TurboFan. Liftoff pode gerar código muito mais rapidamente do que TurboFan, o que permite tempos rápidos de inicialização. TurboFan, por outro lado, pode gerar códigos mais rápidos, permitindo alto desempenho máximo.
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.