Update runtime.md for Preview 1

[jamesmontemagno]

Please update the release notes here as needed for Preview 1.

/cc @richlander

[hez2010]

I experimented with GitHub Copilot to generate a release note by pulling all PRs manually using the GitHub GraphQL API and then delegating the filtering/summarization work to multiple subagents on each category (otherwise it always misses a lot of changes). Sharing the result here:

Details

.NET Runtime in .NET 11 Preview 1 - Release Notes

.NET 11 Preview 1 includes new .NET Runtime features & performance improvements.

Feature

This preview’s runtime work is centered around:

• Runtime async: a new runtime-level async mechanism (including configuration, diagnostics, and AOT support).
• CoreCLR on WebAssembly: CoreCLR support in the WebAssembly SDK plus new browser-host features (threading/timers/interop).
• Interpreter expansion: more IL coverage, better integration (async/ReJIT/debugging), plus new ports.
• Targeted performance work: JIT improvements, interpreter call and compilation performance improvements, and faster WASM allocation paths.

.NET Runtime updates in .NET 11:

• What's new in .NET 11 documentation

Runtime async

Runtime async is a major runtime feature in .NET 11 that introduces new runtime-level infrastructure for async methods, including runtime-generated thunks/continuations and a runtime-visible “async method variant” concept. The goal is to enable new execution modes and improve performance characteristics of async-heavy codepaths, while keeping tooling and AOT scenarios working.

What changed in Preview 1

• Enabled by default in CoreCLR configuration: the CoreCLR configuration default for RuntimeAsync is now enabled (RuntimeAsync=1 by default). This turns on runtime async support in the runtime without forcing the compiler feature across all library code. (dotnet/runtime#121732)
• Behavior alignment for await/continuations: runtime-async callable thunks are made “transparent” so that they don’t accidentally re-introduce classic await posting behavior (captured SynchronizationContext / thread pool) in cases where the configured await semantics should be preserved. This reduces observable behavioral differences between runtime async and traditional async execution. (dotnet/runtime#120386)
• Debugging & diagnostics support:
  • The runtime can now surface debug information for runtime async methods (state machine and continuation data) via a new JIT↔EE reporting API and a refactored debug-info blob format. This improves stepping/inspection experiences for runtime-async frames. (dotnet/runtime#120303)
  • Cordb can read runtime-async continuation objects via APIs such as CordbObjectValue::GetFieldValue, even when dynamically-generated continuation types don’t carry full metadata. (dotnet/runtime#121432)
  • ILVerify recognizes the IL-level async flag so verification understands the intended async representation. (dotnet/runtime#121503)
• AOT and compiler-toolchain support:
  • AOT tools pass the async flag to the JIT when compiling runtime-async methods, and the runtime type system gains AsyncMethodDesc to represent async-call-convention method variants. (dotnet/runtime#120772, dotnet/runtime#120858)
  • ReadyToRun / ILCompiler implement getAsyncInfo to provide async information to the JIT, enabling compilation of runtime-async methods in AOT pipelines. (dotnet/runtime#120859)
  • NativeAOT adds runtime-async continuation support and virtual-method support for runtime-async methods, expanding compatibility for async-heavy applications in AOT deployments. (dotnet/runtime#121398, dotnet/runtime#121443)
• Interop compatibility: built-in COM interop excludes runtime-async call-convention methods from CCW vtables and GUID calculations to preserve existing COM surface behavior and identifiers. (dotnet/runtime#122195)

Impact and how to use

• If you just run .NET apps: the runtime-side support is enabled by default via RuntimeAsync. Most apps won’t need a specific action unless they’re experimenting with runtime async at the compiler level.
• If you want to experiment with runtime-async compilation: you’ll need a compiler/toolchain that can emit the runtime-async representation (e.g., the compiler feature mentioned in dotnet/runtime#121732).
• If you use AOT (ReadyToRun/NativeAOT): Preview 1 includes foundational support so runtime-async methods can be compiled and diagnosed (including continuation support and toolchain plumbing).

WebAssembly

CoreCLR on WebAssembly: SDK, packaging, and hosting

CoreCLR is now a first-class target in the WebAssembly SDK and browser-hosted CoreCLR gained core hosting/runtime features.

• CoreCLR support in the WebAssembly SDK: connects in-tree CoreCLR artifacts, defines CoreCLR-oriented defaults, and decouples Mono’s native build where applicable. (dotnet/runtime#122495)
• Browser runtime packs for CoreCLR: adds packaging/layout pieces needed to ship a browser-hosted CoreCLR runtime pack. (dotnet/runtime#121174)
• Runtime features for browser-hosted CoreCLR: enables async Main, thread pool, and timers in the browser host. (dotnet/runtime#120976)
• Runtime option propagation: browser host can apply runtime options so that linker-related features work as expected in hosted scenarios. (dotnet/runtime#123331)
• Globalization prerequisites: browser-hosted CoreCLR can download ICU to support globalization scenarios. (dotnet/runtime#121800)
• JavaScript numeric interop: enables BigInt support in browser-hosted CoreCLR on WASM. (dotnet/runtime#121025)

Node.js and corerun workflows

• CoreCLR corerun on Node.js: enables Node.js as a host for CoreCLR-on-WASM corerun, including statically-linked dependencies, host filesystem access, and environment propagation. (dotnet/runtime#119250)
• More consistent corewasmrun builds: aligns artifact layout for WASM’s corerun equivalent with other corerun scenarios, simplifying the workflow. (dotnet/runtime#119029)
• Support larger workloads: allows linear-memory growth for corerun on WASM. (dotnet/runtime#120844)

WebAssembly interop and execution features

• Call into UnmanagedCallersOnly from WASM: adds support for calling UnmanagedCallersOnly functions on WASM via runtime-provided entry points similar to reverse P/Invoke stubs. (dotnet/runtime#121359)
• Portable EntryPoint (initial): starts the Portable EntryPoint work, developed in a WASM-agnostic manner but initially scoped to WASM scenarios. (dotnet/runtime#119178)

WebAssembly performance improvements

This preview adds faster allocation helpers and reduces overhead in common interop cases.

• Faster allocation paths:
  • RhpNewFast allocators. (dotnet/runtime#120896)
  • RhpNewArrayFastAlign8. (dotnet/runtime#120690)
• Lightweight enum marshalling: enums can use the lightweight marshaller where applicable, reducing interop overhead. (dotnet/runtime#118991)

WebAssembly JIT (RyuJit)

WASM-targeting JIT bring-up

.NET 11 Preview 1 begins bringing up a WASM-targeting RyuJit, including build system support and Crossgen2 integration work needed for AOT/JIT pipelines.

• Create a WASM-targeting RyuJit (target defines/factoring/build support): (dotnet/runtime#121341)
• Integrate with Crossgen2 and continue factoring for bring-up: (dotnet/runtime#121563)

Interpreter (CoreCLR)

What’s new

The CoreCLR interpreter continues to expand its supported IL surface and execution features, improving compatibility when the interpreter is enabled (notably for WASM/iOS scenarios) and improving debugging and toolchain integration.

New IL and call features supported by the interpreter

• Add mkrefany, refanyval, and refanytype support. (dotnet/runtime#118753)
• Implement tailcalls (CALL/CALLVIRT). (dotnet/runtime#118901)
• Implement pinned IL locals. (dotnet/runtime#118975)
• Implement STELEM_U1 and STELEM_U2. (dotnet/runtime#119026)
• Implement CEE_CKFINITE. (dotnet/runtime#119548)
• Implement CEE_JMP. (dotnet/runtime#121130)
• Reverse P/Invoke support under the interpreter. (dotnet/runtime#119133)
• P/Invoke calli support under the interpreter. (dotnet/runtime#119356)

Interpreter runtime integration (async, ReJIT, debugging)

• Runtime async support in the interpreter (context capture/restore + suspend/resume instruction set). (dotnet/runtime#121862)
• Synchronized methods support. (dotnet/runtime#120006)
• ReJIT support under the interpreter. (dotnet/runtime#122626)
• User breakpoints (System.Diagnostics.Debugger.Break()) in interpreted code. (dotnet/runtime#121911)
• Ability to build clr-interp in Release on desktop via a build flag (enables broader performance testing/usage). (dotnet/runtime#121850)

Interpreter platform ports and interop

• Interpreter enabled for ARM32 SOFTFP. (dotnet/runtime#120688)
• CoreCLR interpreter port to riscv64. (dotnet/runtime#121276)
• Unmanaged thiscall calling convention support, including Windows Arm64 ABI specifics. (dotnet/runtime#122600, dotnet/runtime#123519)

Interpreter performance improvements

• Faster interpreter calls by reducing per-invocation setup and avoiding unnecessary prestub work. (dotnet/runtime#120067)
• Improved compilation performance for very large methods in the interpreter compiler (algorithmic improvements). (dotnet/runtime#119514)
• Delegate tail-calling support and improved delegate handling, including WASM scenarios. (dotnet/runtime#120205)

JIT

Performance improvements

These changes focus on improving startup throughput, enabling more optimizations, and reducing overhead in key code patterns.

• Raise the Multicore JIT MAX_METHODS limit to better support large workloads and improve startup throughput in method-heavy apps. (dotnet/runtime#119359)
• Optimize stackalloc zeroing on Arm64 via STORE_BLK to reduce instruction count and improve throughput for stack allocations. (dotnet/runtime#121986)
• Generalize pattern-based induction-variable (IV) analysis to enable more loop analysis cases, opening the door to more loop optimizations. (dotnet/runtime#119537)
• Extract bitfields directly from parameter registers without spilling in more cases, improving codegen for certain struct/argument shapes. (dotnet/runtime#112740)
• Always create FIELD_LIST for promoted struct arguments in physical promotion, removing older backend-era constraints. (dotnet/runtime#118778)
• Devirtualize non-shared generic virtual methods to reduce virtual-call overhead and enable further inlining/optimization opportunities. (dotnet/runtime#122023)

New/experimental SIMD work

• Introduce TYP_SIMD as an experimental JIT type for Vector<T> on Arm64, gated by DOTNET_JitUseScalableVectorT=1. This is an enabling step for future scalable-vector work. (dotnet/runtime#121548)

GC

New capabilities

• GC heap hard limit support is now available for 32-bit processes, improving operational control over heap growth in constrained 32-bit environments. (dotnet/runtime#101024)

Threading & Synchronization (CoreCLR)

Runtime subsystem improvements

CoreCLR moves more of its waiting/synchronization infrastructure onto the shared managed wait subsystem.

• Move CoreCLR over to the shared managed wait subsystem, reducing reliance on the Win32 PAL wait path for managed code. (dotnet/runtime#117788)
• Port cross-process shared mutex logic into managed code to work alongside the managed wait subsystem. (dotnet/runtime#117635)

NativeAOT / Hosting

New capabilities and operational improvements

• Implement Thread.Interrupt on NativeAOT on Windows, improving feature parity for interruption-based patterns. (dotnet/runtime#118968)
• Add DOTNET_DbgCreateDumpToolPath to locate createdump in NativeAOT scenarios where it isn’t shipped alongside the runtime. (dotnet/runtime#122989)
• Increase file descriptor limits in NativeAOT executables to better support FD-heavy workloads. (dotnet/runtime#118995)

Diagnostics (DAC / cDAC)

Expanded cDAC functionality

This preview expands cDAC’s ability to describe GC state and ship the data needed for postmortem diagnostics.

• Add the cDAC GC Contract and supporting descriptor mechanisms. (dotnet/runtime#118050)
• Save cDAC datadescriptor JSON blobs into minidumps to improve postmortem diagnostics. (dotnet/runtime#121360)
• Publish the cDAC managed transport package. (dotnet/runtime#120851)

New cDAC APIs for profiling and inspection (selected)

These APIs improve what tools like SOS and diagnostics stacks can retrieve and present.

• IXCLRDataMethodInstance::GetName and related stack-walk APIs. (dotnet/runtime#118966)
• GetReJITInformation. (dotnet/runtime#119111)
• GetILForModule. (dotnet/runtime#118546)
• GetMethodDescFromToken. (dotnet/runtime#118619)
• Remaining GC data APIs (heap/segment/OOM/interesting info). (dotnet/runtime#119324)

Architecture coverage

• Add riscv64 managed unwinder for cDAC. (dotnet/runtime#117436)
• Add loongarch64 managed unwinder for cDAC. (dotnet/runtime#121039)

Mono Runtime

New capabilities and performance-related configuration

• Add an UnhandledException hook for finalizer scenarios in Mono, improving exception reporting/behavior in finalizer execution paths. (dotnet/runtime#118563)
• Enable the compressed interface bitmap by default and provide runtime configuration to manage adoption. (dotnet/runtime#119694, dotnet/runtime#119881)

Architecture enablement

RISC-V and s390x improvements

• Add initial RISC-V “C” extension support (compressed integer register-register ops, alignment/unwind updates, and related tooling adjustments). (dotnet/runtime#117408)
• Add RISC-V Zbs extension support (single-bit instructions). (dotnet/runtime#115335)
• Add SIMD fallback support for older / unsupported s390x generations. (dotnet/runtime#118376)

[jamesmontemagno]

Merge when ready

[jamesmontemagno]

@richlander thoughts here

[agocke]

@hez2010's summary is quite good. I'd trim out the bits that have no user-visible impact, but it is on the right track. How should we add things here?

[AndyAyersMS]

His summary was merged into the main PR: #10221, see runtime.md.

I suppose we can still edit that? When is the deadline?

[jongalloway]

@agocke @AndyAyersMS You can push commits to #10221 (dotnet-11-preview1) until we merge which is looking pretty soon, or create an update PR against main later today.