[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 ?

[jkotas]

STACK_SIZE is more interesting.

Stack size is user observable. Smaller stack size should be better for perf, but it can break user apps. I think it is ok to change it for CoreCLR. It is a breaking change though. We may want to mention it in the Mono -> CoreCLR breaking change notice that we are going to file eventually.

I remember you said <20MB should be possible

This comment was about the GC heap size specifically. It was not about the total memory consumption.

do you have specific concern or just curiosity?

What is the user observable impact of this change? For example, do you see a smaller working set reported by the OS for a typical wasm app or test? Can this regress startup time for a typical wasm app? (I assume that the growing memory has some time overhead, hopefully it is neglible.)

You will always see me asking questions on perf-related PRs that do not have any numbers in the descriptions ;-)

[pavelsavara]

/ba-g known infra issue

[pavelsavara]

You will always see me asking questions on perf-related PRs that do not have any numbers in the descriptions ;-)

@jkotas we are getting there. Macrobenchmark can now run measurement on PR/branch.

It will take some time until the code flows thru VMR into preview builds.