[browser][coreCLR] R2R: Runtime shard consumer — lazy IL shard load

[pavelsavara]

Runtime shard consumer: lazy IL shard load

Part of #130524.

Status: draft / issue candidate · Area: CoreCLR-on-WASM runtime, assembly loading · Related: #130523 (splitter/producer), #130522 (R2R over in-memory IL), #130516 (R2R-shard trigger/loader)

Goal

The runtime-side consumer of the shard layout #130523 produces: resolve and load IL namespace-shards on demand, so only the shards an app actually exercises are brought in, rather than eagerly loading every shard. It uses the facade's type-forwarders plus the boot-config namespace/shard metadata, and coordinates with the R2R lazy-load path.

Why

Splitting IL into shards (#130523) only pays off if the runtime can bring shards in lazily. This work turns the static shard layout into on-demand loading, so download and load cost track what the app uses.

Direction

• Ride the forwarder → assembly resolution. When a forwarded type is first needed, the runtime resolves it to its shard assembly; the consumer supplies or fetches that shard per its boot-config asset. The namespace metadata is a secondary index for grouping and pre-fetch.
• Coordinate with the R2R lazy path. Shard loading aligns with the interpreter-driven, async-tolerant hot-path streaming already planned for R2R, so a shard is fetched where blocking is acceptable rather than mid-execution.
• JSPI is explicitly out of scope. No synchronous fault-in of a download via JSPI. The consumer targets async-tolerant load points (interpreter keeps running, pre-fetch, load at safe points) instead of blocking a synchronous type resolution on a network fetch.
• Behavior stays identical. An app using shards behaves the same as one with monolithic assemblies; the split is invisible except for load timing.

Scope

In: on-demand shard resolution and loading driven by the facade forwarders plus boot-config metadata; coordination with the R2R lazy-load path; an async-tolerant load strategy.

Out: the build-time splitter (#130523); the R2R-shard fetch/instantiate (owned by #130516 — this consumer handles IL shards only); JSPI-based synchronous IL fault-in; precompilation.

Success criteria

• An app loads only the shards it exercises (plus the facade), with identical behavior.
• Shard loads happen at async-tolerant points without requiring synchronous blocking on downloads.
• Works together with the R2R lazy-load path and with the R2R metadata reuse ([browser][coreCLR] R2R: R2R that loads against IL already in memory #130522).

Open questions

• Which load points are safe and async-tolerant without JSPI (pre-fetch heuristics, interpreter yield points), and how to avoid a synchronous resolve stalling on a not-yet-resident shard.
• The trigger contract shared with the R2R lazy path, so a hot method and its IL shard are brought in coherently.
• Fallback behavior if a needed shard is not yet resident at a synchronous resolution point.

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.