Skip to content

[browser][coreCLR] R2R: Produce the WASM interpreter PGO profile package (optimization.browser-wasm.MIBC.Runtime) #132718

Open

Description

@pavelsavara

Part of #130524. Related: #130517 (interpreter instrumentation), #130518 (JS capture trigger), #130521 (WASM RyuJIT PGO).

Goal

Turn the WASM interpreter's PGO capability into a maintained optimization-data package — a browser-wasm interpreter-startup profile that flows into the CoreLib R2R build the same way the desktop MIBC packages do today.

Why

The interpreter can produce a block-count profile (#130517) and a developer can capture it from a browser run (#130518). To use that for precompilation in shipping builds, the profile must be collected from a representative workload by CI, packaged, and flowed into the product automatically — not captured by hand.

Scope

In:

  • Collection harness (real browser). Run a representative Blazor WASM workload under headless Chrome (Playwright); arm the capture at startup (DOTNET_DiagnosticPorts=js://pgo, interpreter PGO enabled); drive the in-session stop/flush; capture the downloaded .nettrace. A real-browser profile is required to represent the Blazor WASM product faithfully (a headless-Node in-process capture is a possible lighter-weight fallback).
  • Convert to .mibc. dotnet-pgo create-mibc, referencing the IL-trimmed (linked) assemblies whose MVIDs match the trace. ILLink regenerates the module MVID and webcil preserves it, so the untrimmed runtime-pack assemblies will not match — the trimmed linked assemblies must be used.
  • Package as optimization.browser-wasm.MIBC.Runtime in the .NET optimization-data pipeline, modeled on the existing non-desktop (Android) MIBC path.
  • Dependency flow. Flow the package version into the product (VMR → runtime) automatically via the standard optimization-data subscription mechanism.

Out: interpreter instrumentation (#130517); the JS trigger (#130518); the runtime-side consumption wiring (separate issue); enabling R2R for the WASM CoreLib.

Direction / notes

  • MIBC is IL-level and architecture-independent; the new package adds WASM interpreter-startup-specific data, versus the desktop-workload profiles currently reused for browser/wasm by fallback.
  • Model the producer on the existing Android MIBC path (a non-desktop RID MIBC package already collected on an emulator), adapting collection to the browser harness and referencing the wasm linked (trimmed) assemblies.

Success criteria

  • CI produces a browser-wasm profile and publishes optimization.browser-wasm.MIBC.Runtime.
  • The package version flows into the product automatically.
  • The profile converts and merges via existing tooling with no toolchain changes.

Open questions

  • Harness stability/cost in CI (headless Chrome, download capture).
  • Which representative workload(s) best reflect startup hotness for the Blazor WASM product.
  • Refresh cadence.
  • EventPipe provider/keyword selection for the capture.

Note

This issue was drafted with GitHub Copilot assistance.

Activity

  1. added this to the 12.0.0 milestone on Aug 24, 2026
  2. self-assigned this
    on Aug 24, 2026
  3. dotnet-policy-service commented on Aug 24, 2026

    @dotnet-policy-service
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

  • Status
    No status

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions