.NET 11 preview 3: novidades no runtime, JIT e WebAssembly

O que é o runtime async

O runtime async é uma das maiores apostas técnicas do .NET 11. Trata-se de uma infraestrutura em nível de runtime para métodos assíncronos.

Hoje, o compilador C# transforma cada método async em uma state machine em tempo de compilação. O runtime async muda essa abordagem e delega o gerenciamento de continuações diretamente ao runtime.

No modelo tradicional, o compilador gera um tipo que implementa IAsyncStateMachine e usa um builder, como o AsyncTaskMethodBuilder, para coordenar a execução. Quando o método realmente suspende em um await, esse estado precisa ir para o heap.

Além disso, cada método assíncrono acrescenta frames de infraestrutura à pilha. Por isso, o código gerado fica maior e o diagnóstico fica mais difícil do que no código síncrono equivalente.

Com o runtime async, o compilador emite métodos marcados para o runtime, que cuida da suspensão e da retomada. Na prática, o mesmo async e await que você já escreve passa a ser executado por um mecanismo nativo da plataforma.

O objetivo é reduzir o overhead em caminhos assíncronos intensos e melhorar ferramentas como stack traces e profilers. Por exemplo, a documentação oficial mostra uma pilha de chamadas que cai de 13 para 5 frames quando o recurso está ativo.

// Com <Features>runtime-async=on</Features> no .csproj
await ProcessOrderAsync();

static async Task ProcessOrderAsync()
{
    await Task.Yield();
    await SaveOrderAsync();
}

static async Task SaveOrderAsync()
{
    await Task.Yield();
    // A pilha mostra apenas os métodos reais, sem a infraestrutura da state machine
    Console.WriteLine(new System.Diagnostics.StackTrace(fNeedFileInfo: true));
}

Em outras palavras, profilers, logs de diagnóstico e a janela de call stack do depurador passam a refletir a cadeia real de chamadas.

Suporte a NativeAOT e ReadyToRun

O .NET 11 Preview 3 também inclui suporte ao runtime async para NativeAOT e ReadyToRun. Assim, o recurso deixa de ficar restrito ao código compilado pelo JIT e alcança cenários de compilação antecipada.

O ReadyToRun pré-compila o IL para código nativo e reduz o tempo de inicialização, mas mantém o JIT disponível. Já o NativeAOT gera um executável totalmente nativo, sem JIT em tempo de execução.

Além disso, houve trabalho para reutilizar objetos de continuação de forma mais agressiva. O runtime também evita salvar variáveis locais que não foram alteradas, o que reduz a pressão de alocação em código com alto volume de operações assíncronas.

Para quem publica APIs com NativeAOT, essa combinação é especialmente interessante. Afinal, menos alocações significam menos trabalho para o garbage collector em serviços com muitas requisições simultâneas.

Expressões switch com múltiplos alvos

Padrões comuns de switch com vários valores constantes agora viram verificações sem desvios desnecessários.

public static bool IsSmall(int x) => x is 0 or 1 or 2 or 3 or 4;

public static string Classify(int statusCode) => statusCode switch
{
    // Vários alvos constantes podem ser dobrados em checagens mais simples
    200 or 201 or 204 => "success",
    400 or 404 or 422 => "client-error",
    _ => "other"
};

Antes, esse padrão podia gerar comparações sequenciais. Com a melhoria, o JIT dobra a lógica em uma verificação mais direta, o que reduz o número de saltos condicionais no código gerado.

Para ter uma ideia, um conjunto contíguo de constantes como 0 a 4 equivale a uma única comparação sem sinal, algo como (uint)x <= 4. Esse tipo de transformação evita desvios difíceis de prever pela CPU, que custam caro quando o processador erra a previsão.

Bounds checks em índice reverso

O acesso a arrays com ^, o índice a partir do fim, já contava com a remoção de bounds checks redundantes. Agora, o .NET 11 Preview 3 amplia essa capacidade para mais padrões do código real.

public static int SumTail(int[] values)
{
    // O JIT consegue eliminar verificações de limite redundantes aqui
    return values[^1] + values[^2];
}

Vale lembrar o que é um bounds check. Sempre que você acessa values[i], o runtime confere se o índice está dentro do array e, se não estiver, lança IndexOutOfRangeException.

Quando o JIT consegue provar que o índice é válido, ele remove essa verificação. Assim, cada bounds check removido é uma comparação a menos dentro de laços quentes, e código que manipula buffers, parsers e algoritmos numéricos tende a ganhar.

Conversão de uint para float e double

Conversões de uint para float ou double ficaram mais rápidas em hardware x86 sem suporte a AVX-512.

public static double ToDouble(uint value)
{
    // Conversão mais rápida em CPUs x86 anteriores ao AVX-512
    double result = value;
    return result;
}

O motivo é técnico. Processadores com AVX-512 têm instruções que convertem inteiros sem sinal diretamente para ponto flutuante, enquanto o conjunto SSE2 só oferece a conversão de inteiros com sinal.

Por isso, em CPUs sem AVX-512, o JIT precisa gerar uma sequência alternativa para tratar o uint. O .NET 11 Preview 3 melhora justamente essa sequência, o que importa em servidores mais antigos e em instâncias de nuvem de gerações anteriores.

Por que essas melhorias importam

É importante entender que essas melhorias se acumulam. O .NET evolui o JIT de forma contínua, e cada preview entrega ganhos que beneficiam código existente sem nenhuma mudança no código-fonte.

A filosofia é clara: você não deveria reescrever código para ganhar performance. Em vez disso, o JIT identifica padrões comuns e gera código de máquina cada vez mais eficiente.

Carregamento de payloads WebCIL

WebCIL é um formato de empacotamento de assemblies .NET adaptado para distribuição via HTTP no navegador. O .NET 11 Preview 3 adiciona o carregamento desse formato no CoreCLR para WebAssembly.

O formato existe por um motivo prático. Alguns firewalls e antivírus bloqueiam o download de arquivos .dll, então o WebCIL empacota o IL em um formato que passa por esses filtros sem problemas.

No Mono, o WebCIL já é usado há algumas versões.

A novidade agora é o suporte no CoreCLR, o que faz parte do trabalho de longo prazo para unificar a execução do .NET entre servidores e navegadores. Assim, a meta é que uma aplicação Blazor WebAssembly aproveite as mesmas otimizações de JIT e GC disponíveis no servidor.

Símbolos e stack traces melhores

Depurar aplicações WebAssembly sempre foi desafiador. Nesta versão, a qualidade dos símbolos de depuração e a precisão das stack traces no navegador melhoraram.

Isso ataca uma das queixas mais comuns da comunidade. Afinal, stack traces de código assíncrono no navegador costumavam perder o sentido a partir do primeiro await.

Marshal direto de float[] e Span

O .NET 11 Preview 3 também passa float[], Span<float> e ArraySegment<float> de forma mais direta pela fronteira com o JavaScript.

using System.Runtime.InteropServices.JavaScript;

public static partial class ChartInterop
{
    // Envia um array de floats para uma função JavaScript importada
    [JSImport("renderSeries", "chart.js")]
    public static partial void RenderSeries(float[] values);
}

Essa melhoria é relevante para computação numérica e machine learning no navegador. Nesses cenários, transferir arrays de ponto flutuante entre .NET e JavaScript costumava ser um gargalo.

Historicamente, o interop baseado em JSImport e JSExport priorizava tipos como byte, int e double em arrays e spans. Dessa forma, quem trabalhava com float precisava converter os dados antes de cruzar a fronteira, pagando cópias e alocações extras.