[browser][coreCLR] R2R: R2R composite for the startup set

[pavelsavara]

R2R composite for the startup set (follow-up to per-assembly)

Part of #130524.

Status: draft / issue candidate · Area: CoreCLR-on-WASM, precompilation/R2R · Related: #130522 (R2R over in-memory IL), #130523 (sharded IL), D4 · Builds on the upstream per-assembly R2R + webcil-in-wasm async-load foundation (#129634).

Goal

Combine the per-assembly startup R2R images into a single composite image, so the precompiled startup and hot code ships and loads as one unit rather than many per-assembly files. This is the follow-up to the first prototype's per-assembly R2R (D4).

Why

Per-assembly R2R is the simplest first step, but many small images mean more files, more per-image load/instantiate/fixup overhead, and cross-image calls that go through import indirection. A composite consolidates the startup set into one image with direct intra-composite calls and a single load — better code quality (fewer cross-image thunks) and more efficient startup load.

Direction

• One composite for the profile-selected startup + hot set, instead of one image per assembly.
• Direct intra-composite calls; calls out to code not in the composite fall back through the normal import/interpreter path.
• Browser-loadable packaging. The composite must be emitted in the loadable-on-WASM form, not a desktop-only shape.
• Coordinate with in-memory-IL reuse ([browser][coreCLR] R2R: R2R that loads against IL already in memory #130522) and sharded IL ([browser][coreCLR] R2R: IL splitter — shard trimmed assemblies by namespace #130523). The composite binds against the resident IL the same way the per-assembly images do, including when that IL is a facade plus shards.

Scope

In: producing a single startup composite from the profile; loadable-on-WASM packaging; direct intra-composite calls with coherent fallback.

Out: the per-assembly R2R baseline (the prototype path); lazily-streamed shard R2R; the IL splitter/consumer.

Success criteria

• The startup hot set ships and loads as one composite; behavior identical to the per-assembly set.
• Measurable reduction in cross-image thunking and/or load overhead versus per-assembly R2R.

Open questions

• Whether the composite container is fully browser-loadable today or needs work (the component-file form may be desktop-shaped).
• How the composite interacts with the in-memory-IL reuse ([browser][coreCLR] R2R: R2R that loads against IL already in memory #130522) and sharded-IL ([browser][coreCLR] R2R: IL splitter — shard trimmed assemblies by namespace #130523) layouts.
• Selection boundary: exactly which assemblies/methods go in the startup composite versus stay per-assembly or lazy.

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.