[browser][coreCLR] R2R: Enable PGO instrumentation for the WASM RyuJIT

[pavelsavara]

Enable PGO instrumentation for the WASM RyuJIT

Part of #130524.

Status: draft / issue candidate · Area: CoreCLR JIT, PGO, WASM build · Related: #130517 (interpreter PGO producer)

Goal

Bring the full dynamic-profile (PGO) subsystem online for the WebAssembly RyuJIT target, so the JIT on WASM can both produce and consume profile data at parity with the desktop runtime. This is the follow-up that removes the platform limitation #130517 works around, and it is the general enabler for profile-guided precompilation and codegen on WASM.

Why

PGO (and tiered compilation) are currently disabled for the browser/WASM build, so the shared profile subsystem and the JIT's profiling entry points are absent or stubbed there. As long as that is the case, only a narrow interpreter-only producer (#130517) is possible, and the JIT cannot participate in profiling at all. Enabling the feature is the difference between a one-off prototype path and durable, first-class PGO support on WASM.

Direction

• Turn on the profile feature for the WASM build so the shared profile subsystem exists and the JIT's instrumentation and consumption paths are live rather than stubbed.
• Decouple profiling from tiered compilation on WASM. Tiered compilation is off for this target, and the existing profiling path assumes tiering eligibility. PGO must work without that assumption — either by separating the two concerns or by providing a WASM-appropriate trigger for collecting and applying profiles.
• Validate produce-and-consume on WASM. Confirm the JIT can emit instrumented code, that counts flow into the shared representation, and that a collected profile is read back to guide optimized precompilation/codegen — the same round trip the desktop runtime supports.

Scope

In: enabling the profile feature in the WASM build configuration; reconciling profiling with the tiering-off reality on WASM; validating the JIT produce/consume round trip on WASM.

Out: interpreter-side counting (that is #130517); precompiled-code packaging and loading; profile-export transport specifics.

Success criteria

• The WASM RyuJIT produces and consumes profile data equivalently to the desktop runtime.
• The two producers — the interpreter ([browser][coreCLR] R2R: Interpreter PGO instrumentation (block counts) #130517) and the JIT — emit the same profile format, so downstream tooling is identical regardless of source.
• The enabled configuration is a supported, tested build shape, not a one-off.

Dependencies & relationship to #130517

• Complements [browser][coreCLR] R2R: Interpreter PGO instrumentation (block counts) #130517. The interpreter producer can run even before this feature is fully on; this work makes the whole feature first-class. Together they settle the "how do we get PGO on WASM" decision: interpreter-only subset now ([browser][coreCLR] R2R: Interpreter PGO instrumentation (block counts) #130517), full JIT enablement as the durable follow-up (this work).
• Sequencing: [browser][coreCLR] R2R: Interpreter PGO instrumentation (block counts) #130517 can proceed against a minimal/interim subset; this work should land to make that producer sit on the same supported foundation the JIT uses.

Open questions

• Is profiling-without-tiered-compilation a supported and tested configuration, and what work is needed to make it one on WASM?
• Build-size and complexity cost of enabling the feature for WASM, and whether any of it should be opt-in.
• Any WASM-specific gaps in emitting instrumented code or in reading profiles back for codegen.

Note

This issue was drafted with GitHub Copilot assistance.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.