.NET 11 Preview 5: todas as novidades do runtime

Integração com on-stack replacement

A maior melhoria do Preview 5 nessa área envolve o on-stack replacement (OSR) do JIT. O OSR permite que um método de longa execução troque seu código inicial por código otimizado enquanto ainda roda, sem encerrar a chamada.

Antes do Preview 5, contudo, havia um custo escondido. Quando um método assíncrono otimizado por OSR retomava após uma suspensão, o runtime percorria o caminho de transição de propósito geral do OSR, com overhead de 10x a 20x.

Agora, o runtime-async retoma esses métodos diretamente no código otimizado e ignora a transição geral. Com isso, um benchmark focado em suspensões caiu de 6357.1 ms para 457.1 ms, uma redução de aproximadamente 93%.

Código menor, menos TLS e continuações reutilizadas

Além da integração com OSR, o preview entrega outras três melhorias no runtime-async. Primeiro, os caminhos de suspensão mais comuns agora geram código menor.

Nesse caso, o microbenchmark de referência registrou ganho de aproximadamente 8%. O código gerado, por sua vez, encolheu de 766 bytes para 751 bytes.

Em seguida, a suspensão e a retomada passaram a fazer menos trabalho com thread-local storage. Elas também evitam diversas write barriers nos caminhos quentes, e o benchmark de referência caiu de 350.3 ms para 291.3 ms.

Por fim, o runtime-async reutiliza continuações quando um ValueTask baseado em IValueTaskSource suspende. Dessa forma, o runtime elimina uma alocação nesse caminho, algo relevante para bibliotecas de rede e I/O que usam esse padrão.

Como habilitar o runtime-async no projeto

Embora as bibliotecas do runtime do .NET 11 já usem o recurso, projetos de aplicação ainda precisam optar explicitamente. Para isso, basta adicionar a propriedade Features ao arquivo de projeto:

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <!-- Habilita o runtime-async no código da aplicação -->
  <Features>runtime-async=on</Features>
</PropertyGroup>

Depois disso, o compilador deixa de gerar state machines para os métodos do seu projeto. Então, vale rodar a suíte de testes e um profiler para comparar throughput e alocações antes e depois.

Remoção de verificações redundantes em spans

O JIT agora remove mais range checks em loops de span que fatiam repetidamente um prefixo de largura fixa. Esses loops geralmente usam uma verificação de comprimento para saber se ainda há dados suficientes.

No exemplo abaixo, a guarda data.Length >= Vector128<int>.Count prova que as operações seguintes ficam dentro dos limites ao longo da borda de retorno do loop:

int Sum(ReadOnlySpan<int> data)
{
    Vector128<int> sum = default;

    // A guarda de comprimento permite ao JIT eliminar o range check extra
    while (data.Length >= Vector128<int>.Count)
    {
        sum += Vector128.Create(data);
        data = data.Slice(Vector128<int>.Count);
    }

    int result = Vector128.Sum(sum);
    foreach (int item in data)
        result += item;

    return result;
}

Como resultado, o JIT eliminou o bloco de range check adicional. O código gerado caiu de 113 bytes para 79 bytes.

Uma melhoria relacionada de value numbering também remove verificações redundantes em span.Slice(span.Length - constant). Assim, padrões como ler os quatro últimos bytes de um span compilam diretamente para a instrução de load após a guarda inicial.

Além disso, a propagação de null check agora atravessa nós PHI que mesclam um valor recém-criado com um valor não nulo. Para o padrão (_inner ??= new Inner()).Do(n), por exemplo, o JIT descarta a verificação explícita de null antes do branch.

Aritmética menor e casts mais rápidos

O JIT agora transforma CONST - x em x ^ CONST quando informações de intervalo provam que as duas expressões são equivalentes. Parece um detalhe, mas reduz instruções em código de baixo nível.

Para um byte, 255 vale 1111_1111 em binário. Portanto, x ^ 255 inverte exatamente esses oito bits e produz o mesmo resultado que 255 - x.

Na prática, o código gerado para 255 - byte passa de neg mais add para um único xor. Já para -1 - x, o JIT emite apenas not.

Em processadores x86 com AVX-512 ou AVX10.2, os casts de ponto flutuante para long e ulong também melhoraram. Agora eles usam instruções de conversão de hardware em todos os casos sem overflow.

O diff típico de double para long, por exemplo, substitui a chamada ao helper CORINFO_HELP_DBL2LNG pela instrução vcvttpd2qq com tratamento de máscara. Com isso, código numérico intenso ganha desempenho sem nenhuma reescrita.

Novo switch de trimming do GC

O Preview 5 introduz um novo switch de configuração do GC, chamado DOTNET_GCTrimYoungestKeepPercent. Ele atua junto do modo de latência com footprint de memória reduzido, ativado por DOTNET_GCLatencyLevel=0.

Com o switch, esse modo mantém uma porcentagem configurável da geração mais jovem durante o trimming. Assim, a aplicação ganha mais uma forma de equilibrar economia de memória e custo de startup:

# Ativa o modo de footprint reduzido e mantém parte da geração mais jovem
$env:DOTNET_GCLatencyLevel = "0"
$env:DOTNET_GCTrimYoungestKeepPercent = "0xF"

Note que o valor usa notação hexadecimal, como outras configurações do GC. Portanto, 0xF corresponde a 15%.

Trata-se de uma opção avançada, voltada a cenários em que a memória importa muito, como containers pequenos. Por isso, ajuste o valor com benchmarks que representem a carga real da aplicação.

Correção na compactação do heap

Na compactação, a equipe corrigiu um problema em que o watermark heap_segment_used ficava desatualizado após a relocação de objetos em uma região. Esse bug causava a retenção de dados sujos em certas configurações.

Isso acontecia quando large pages ou never_decommit_p faziam decommit_region limpar apenas até used. Como consequência, sobrava uma lacuna obsoleta na região.

Com a correção, os benchmarks de cinco minutos em large pages mostraram aumento de 2,1% no throughput médio. Além disso, o pico de throughput subiu 9,4% e o número de eventos de falta de memória caiu 35%.

Como experimentar o CoreCLR em um projeto Blazor WebAssembly

Neste preview, o CoreCLR para browser funciona por opt-in. Para habilitá-lo em um projeto Blazor WebAssembly que já usa net11.0, adicione a propriedade UseMonoRuntime ao arquivo de projeto:

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <!-- Troca o runtime Mono pelo CoreCLR no browser -->
  <UseMonoRuntime>false</UseMonoRuntime>
</PropertyGroup>

Para confirmar que o aplicativo roda em CoreCLR, abra o console do navegador e execute o comando abaixo:

// Disponível apenas quando a aplicação roda sobre CoreCLR
globalThis.getDotnetRuntime(0).INTERNAL.GetDotNetRuntimeHeap()

O CoreCLR expõe o hook GetDotNetRuntimeHeap, que retorna um Uint8Array. Como o runtime Mono não expõe esse hook, uma chamada bem-sucedida confirma a execução sobre CoreCLR.

Vale lembrar, contudo, que AOT e os caminhos de build nativo ainda dependem do Mono neste preview. Então, use o CoreCLR no browser para testes e feedback, não para produção.

Correções no JIT e no GC

Na geração de código, a equipe corrigiu o tratamento de data breakpoints após inlining de CORINFO_HELP_ARRADDR_ST em x64. Também resolveu inconsistências de perfil em otimizações de flow graph e problemas de alocação de registradores em torno de kills implícitos e liveness local.

Ainda no JIT, houve ajustes no runtime-async com ReadyToRun em RISC-V64 e em loads e stores de vetores e máscaras alocados na stack em Arm64. Além disso, uma falha SIGILL em plataformas Arm64 com SME, mas sem SVE, deixou de ocorrer.

No GC, a afinidade de CPU passou a funcionar em máquinas Unix com mais de 1024 CPUs. A equipe também desabilitou um modo agressivo de coleta de large pages para cenários ReadyToRun.

Correções no NativeAOT, no cDAC e no Mono

No NativeAOT, as correções envolvem GC roots após transições universais e um bug em acesso secundário de dependent handle com GC standalone. Também entraram a preservação do estado de execução abortada nas informações de GC e o parsing hexadecimal de configurações com prefixos 0x e 0X.

Em diagnósticos, o cDAC ampliou o suporte a estado de attach do depurador, flags do compilador, segmentos de heap e APIs de contexto de tipo genérico. Da mesma forma, passou a cobrir assinaturas vararg, layouts de tipo e array, statics de tipos coletáveis e mais enumeração de metadados.

A equipe ainda resolveu dados obsoletos em lastThrownObjectHandle durante o dispatch ativo de exceções. Também eliminou uma falha SIGSEGV no createdump ao incluir frames ativos do interpretador.

No Mono e no interpretador, por fim, os signal handlers voltaram a funcionar durante o encadeamento de crash. O interpretador também ganhou suporte a stack walking no cDAC e um tratamento correto de breakpoints para exceções nativas de first chance.