[browser][coreCLR] reduce initial memory footprint

[pavelsavara]

Fixes #127880

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR reduces the default WebAssembly memory and stack settings used by the CoreCLR browser host, aiming to lower the initial memory footprint during startup (per #127880).

Changes:

• Decrease Emscripten INITIAL_MEMORY from 128 MB to 32 MB for browserhost.
• Decrease Emscripten STACK_SIZE from 5 MB to 2 MB for browserhost.
• Keep the MSBuild CoreCLR WASM relink targets in sync with the browserhost CMake configuration.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/native/corehost/browserhost/CMakeLists.txt	Lowers default INITIAL_MEMORY and STACK_SIZE link options for the browser host to reduce startup footprint.
src/mono/browser/build/BrowserWasmApp.CoreCLR.targets	Mirrors the updated memory/stack defaults in the CoreCLR WASM relink pipeline so app relinks match the host configuration.

[radekdoulik]

LGTM, let see if CI tests will pass. Thank you!

[jkotas]

There are more places where this is hardcoded:

src\mono\browser\browser.proj(219):<EmccStackSize>5MB</EmccStackSize>
src\mono\browser\build\BrowserWasmApp.targets(171):<EmccStackSize Condition="'$(EmccStackSize)' == ''">5MB</EmccStackSize>
src\mono\wasm\build\WasmApp.Common.targets(67):- $(EmccStackSize)                    - Stack size. Default value: 5MB.

Is this inconsistency intentional?

[pavelsavara]

Is this inconsistency intentional?

Yes, that is Mono

[jkotas]

What's the reasoning behind lower limits for CoreCLR? Is there a problem with applying the same lower limits to Mono as well?

[pavelsavara]

What's the reasoning behind lower limits for CoreCLR?

It's "see how low we can set it before things break".

STACK_SIZE is more interesting. We discussed with @davidwrighton that I saw some deep stack traces on the interpreter, but I don't remember where. He said that 2MB should be enough.
And we could possibly weed out some deep interp->native->interp transitions.
The build here is green so, we didn't find the bottom yet.

INITIAL_MEMORY is only about re-allocating the linear memory later, this will not break anything, but possibly make it bit slower to start if this value it too low. I want to see the impact on my macro benchmark. Current value is 128MB which none of the tested/compatible apps need and so currently we are not learning the actual low value from that.

The 32MB is matching Mono default value. I remember you said <20MB should be possible. Do you want to try that ?

Blazor template app uses 84MB large linear memory to start on this branch.

Is there a problem with applying the same lower limits to Mono as well?

STACK_SIZE was changed in #81215 but I don't remember why or what was the previous value.

Mono AOT in particular has big INITIAL_MEMORY footprint growing with size of the code. I think it's about some relocations or trampolines. The initial memory needs to be large enough so that some Mono AOT data segment could be applied by the engine at the initial load. There is dedicated MSBuild logic for calculating it. We may need same thing for R2R later.

Right now Mono is "don't touch it" territory.

@jkotas do you have specific concern or just curiosity ?