[browser][coreCLR] enable bigint

[pavelsavara]

• enable -sWASM_BIGINT=1
• enable -mbulk-memory
• detect max memory size
• don't touch cgroup files on wasm
• don't call memcpy on zero size buffers

Fixes #119639
Fixes #119997
Related #120298 (comment)

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[radekdoulik]

There is also an option to fix the underlying bug in our emscripten fork for our current version. That would take some effort, depends on how much we need this now. @pavelsavara does enabling bigint improve the linking times on your system?

[pavelsavara]

There is also an option to fix the underlying bug in our emscripten fork for our current version.

The fix is in emscripten-core/emscripten#22873, we could do partial backport into our fork.

But I much prefer full upgrade.
See #119409 and #120222

does enabling bigint improve the linking times on your system?

Yes it does make a large difference.

it can be turned off separately, but only by fiddling with minimum browser options, which has more far-reaching effects (e. g. it implies JS transpilation).

Yes

https://github.com/emscripten-core/emscripten/blob/cf90417346b78455089e64eb909d71d091ecc055/tools/link.py#L1383-L1384

-sMIN_CHROME_VERSION=74 does the trick in our version of emscripten.

We would loose NON_TRAPPING_FPTOINT and PROMISE_ANY why is that a big deal @SingleAccretion ?

[SingleAccretion]

We would loose NON_TRAPPING_FPTOINT and PROMISE_ANY why is that a big deal

It is not a big deal. What I was worried about is this https://github.com/emscripten-core/emscripten/blob/8ac7ef7de5b9dc555d83db0f17bbc22346914dba/tools/link.py#L1284-L1299. Looks like it can be turned off via -sPOLYFILL=0. So that (-sWASM_BIGINT=1 -sPOLYFILL=0 -sMIN_CHROME_VERSION=74) seems like a good way forward.

[Copilot]

Pull Request Overview

This PR enables WebAssembly BigInt support and bulk memory operations for the CoreCLR browser runtime. The changes improve WASM compatibility and prevent runtime errors when working with zero-size memory operations.

Key changes:

• Enable -sWASM_BIGINT=1 and -mbulk-memory compiler flags across browser-related build configurations
• Add guards to prevent memcpy calls with zero-size buffers, which can cause issues in WASM
• Skip cgroup file system operations on WASM platform and implement WASM-specific memory size detection

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/tests/CMakeLists.txt	Adds -mbulk-memory flag to test build configuration
src/native/corehost/browserhost/CMakeLists.txt	Enables bulk memory and BigInt flags for browser host
src/coreclr/vm/methodtablebuilder.cpp	Guards ZeroMemory call when field count is zero
src/coreclr/pal/src/misc/cgroup.cpp	Prevents cgroup operations on WASM and guards cgroup path finding
src/coreclr/pal/CMakeLists.txt	Adds -mbulk-memory flag to PAL build
src/coreclr/interpreter/compiler.cpp	Guards multiple memcpy calls against zero-size operations
src/coreclr/hosts/corerun/CMakeLists.txt	Enables bulk memory and BigInt flags for corerun host
src/coreclr/gc/unix/gcenv.unix.cpp	Implements WASM-specific memory size detection using emscripten_get_heap_max()
src/coreclr/gc/unix/cgroup.cpp	Prevents cgroup operations on WASM and guards cgroup path finding

[kg]

Note that recent emscripten has bulk memory as default AFAIK, so if we ever update emscripten this will happen anyway. I think it's still worthwhile to explicitly turn bulk memory on now though even if it will become the default later.

[radekdoulik]

Note that recent emscripten has bulk memory as default AFAIK, so if we ever update emscripten this will happen anyway. I think it's still worthwhile to explicitly turn bulk memory on now though even if it will become the default later.

Yes, and with it we also closer to current mono, which has bulk memory enabled too.

[radekdoulik]

There is also an option to fix the underlying bug in our emscripten fork for our current version.

The fix is in emscripten-core/emscripten#22873, we could do partial backport into our fork.

But I much prefer full upgrade. See #119409 and #120222

Sure, we want to do that anyway.

[pavelsavara]

/ba-g CI timeouts

[AaronRobinsonMSFT]

@pavelsavara This appears to have broken the corerun and node.js scenario in some way. I can run under node.js prior to this but this commit seems to break it.

[pavelsavara]

@pavelsavara This appears to have broken the corerun and node.js scenario in some way. I can run under node.js prior to this but this commit seems to break it.

@AaronRobinsonMSFT
You may need to upgrade your nodeJS to later version. What's the error message and what's your nodejs version ?

@akoeplinger please #120593

[AaronRobinsonMSFT]

@AaronRobinsonMSFT
You may need to upgrade your nodeJS to later version. What's the error message and what's your nodejs version ?

So I just checked on macOS and it works with node.js v24.7. I was hitting the issue on Windows though. My node.js should also be recent - installed the same week as when I was on macOS. For now I can work on macOS and make progress. I will check on Windows again tomorrow.

[AaronRobinsonMSFT]

So I just checked on macOS and it works with node.js v24.7.

Oops, incorrect. Something is amiss here. It is now failing in the same way.