[wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap #100106

kg · 2024-03-21T21:23:23Z

Emscripten's implementations of mmap and malloc have a lot of overhead, particularly time spent calling memset to zero brand new pages it got by growing the heap. During startup we lose a lot of time to this, because we have to reserve space for things like the sgen card tables and the contents of all our dll files (they live in the heap for metadata decoding).

This PR tries using sbrk instead in the hot paths for improved startup, and based on my measurements, it makes most of the time spent in memset go away. It's theoretically a breaking change though since someone could have been relying on the ability to _free the result of mono_wasm_load_bytes_into_heap'd preloaded assets, and our code might be relying on the ability to release pages to the "OS" in wasm?

EDIT: PR updated to not replace all our uses of mmap, and only replace load_bytes_into_heap for now - the rest of them will take more work to replace.

dotnet-policy-service · 2024-03-21T21:23:55Z

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

kg · 2024-03-22T00:18:49Z

/azp run runtime

azure-pipelines · 2024-03-22T00:19:18Z

Azure Pipelines successfully started running 1 pipeline(s).

kg · 2024-03-22T22:56:41Z

As suspected it looks like mono_vfree does need to work on wasm, even though there's not really much point in handing pages back (the heap can't ever shrink and there's no wasm equivalent of MADV_DONTNEED).

src/mono/browser/runtime/assets.ts

SingleAccretion · 2024-03-25T13:33:53Z

mmap and malloc have a lot of overhead, particularly time spent calling memset to zero brand new pages it got by growing the heap

It is expected that the mmap emulation needs to zero pages, but why does malloc do this? It sounds like a bug. malloc doesn't need to return zeroed memory.

kg · 2024-03-25T16:45:39Z

mmap and malloc have a lot of overhead, particularly time spent calling memset to zero brand new pages it got by growing the heap

It is expected that the mmap emulation needs to zero pages, but why does malloc do this? It sounds like a bug. malloc doesn't need to return zeroed memory.

During startup malloc == mmap

EDIT: And looking at another profile, dlcalloc also calls memset, and we use it for our malloc0 (this is another case where it's technically right to memset, but unnecessary if the pages were just created by sbrk)

kg · 2024-03-27T01:48:40Z

Experimenting with reconfiguring dlmalloc on wasm to use sbrk instead of emscripten mmap/munmap, since they're fake.

kg · 2024-03-27T17:06:05Z

Since we determined that we shouldn't be using dlmalloc at all, removing the dlmalloc change. It did work, though.

…avoid the overhead of emscripten's mmap HACK: Use sbrk instead of mmap to allocate wasm pages, to skip memset. Disable vfree. Fix build Revert mmap experiment

Fix build

This reverts commit 0024b82.

pavelsavara · 2024-04-02T11:41:18Z

I can see --zero-filled-memory in wasm-opt args on some of my CI lane, maybe that makes difference ?

Wasm.Console.Bench.Sample -> /__w/1/s/src/mono/sample/wasm/browser-bench/Console/bin/browser-wasm/Wasm.Console.Bench.Sample.dll
  Compiling native assets with /usr/local/emscripten/emsdk/upstream/emscripten/emcc with -Oz. This may take a while ...
  [1/4] corebindings.c -> corebindings.o [took 0.32s]
  [2/4] pinvoke.c -> pinvoke.o [took 0.33s]
  [3/4] driver.c -> driver.o [took 0.34s]
  [4/4] runtime.c -> runtime.o [took 0.36s]
  Linking for initial memory $(WasmInitialHeapSize)=33554432 bytes. Set this msbuild property to change the value.
  Linking with emcc with -O2. This may take a while ...
   "/usr/local/emscripten/emsdk/node/14.18.2_64bit/bin/node" /usr/local/emscripten/emsdk/upstream/emscripten/src/compiler.js /tmp/tmpiu3cpv7n.json --symbols-only
   "/usr/local/emscripten/emsdk/upstream/bin/wasm-ld" -o /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/dotnet.native.wasm /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/pinvoke.o /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/driver.o /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/corebindings.o /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/runtime.o /__w/1/s/artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Release/runtimes/browser-wasm/native/libicudata.a /__w/1/s/artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Release/runtimes/browser-wasm/native/libicui18n.a /__w/1/s/artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Release/runtimes/browser-wasm/native/libicuuc.a /__w/1/s/artifacts/bin/microsoft.netcore.ap...
   "/usr/local/emscripten/emsdk/node/14.18.2_64bit/bin/node" /usr/local/emscripten/emsdk/upstream/emscripten/src/compiler.js /tmp/tmp1vo_lkp4.json
   "/usr/local/emscripten/emsdk/upstream/bin/wasm-opt" --post-emscripten -O2 --low-memory-unused --zero-filled-memory --pass-arg=directize-initial-contents-immutable --strip-producers /__w/1/s/artifacts/obj/mono/Wasm.Console.Bench.Sample/browser.wasm.Release/browser-wasm/wasm/for-build/dotnet.native.wasm -o /__w/1/s/artifacts/obj/mono/
...

pavelsavara · 2024-04-09T18:27:03Z

I'm bit sad we didn't see this to pass

kg · 2024-04-09T18:52:33Z

I'm bit sad we didn't see this to pass

It passed a few times before, so I was pretty comfortable not re-running it

…es into heap (dotnet#100106) Use sbrk to allocate persistent space for large load_bytes_into_heap calls to avoid the startup overhead of emscripten's malloc and memset for the new space

kg added the arch-wasm WebAssembly architecture label Mar 21, 2024

dotnet-issue-labeler bot added the area-VM-meta-mono label Mar 21, 2024

dotnet-policy-service bot assigned kg Mar 21, 2024

kg mentioned this pull request Mar 21, 2024

WASM startup time optimization tracking issue #63809

Open

This was referenced Mar 22, 2024

System.Text.Json failing some large file tests #59678

Closed

[browser][MT] Unhandled JS error #97546

Closed

[browser][MT] TIMED_OUT but 0 was expected #99888

Closed

kg force-pushed the wasm-sbrk branch from aea6a9c to 00dfcd7 Compare March 22, 2024 22:58

kg changed the title ~~[wasm] use sbrk instead of emscripten mmap where possible~~ [wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap Mar 22, 2024

kg marked this pull request as ready for review March 22, 2024 22:59

kg requested review from lewing and pavelsavara as code owners March 22, 2024 22:59

build-analysis bot mentioned this pull request Mar 23, 2024

[ci] Playwright test times out/fails because target closed #99961

Closed

pavelsavara approved these changes Mar 25, 2024

View reviewed changes

src/mono/browser/runtime/assets.ts Show resolved Hide resolved

kg requested review from lambdageek and steveisok as code owners March 27, 2024 01:00

This was referenced Mar 27, 2024

[browser][MT] MutexTests - operation does not support unaligned accesses #96191

Open

Browser SignalRClientTests failing in CI #100307

Closed

kg force-pushed the wasm-sbrk branch from 8b72ae1 to 34ed5c4 Compare March 27, 2024 17:05

kg added 3 commits March 27, 2024 10:32

Add new persistent version of load_bytes_into_heap that uses sbrk to …

6a72e26

…avoid the overhead of emscripten's mmap HACK: Use sbrk instead of mmap to allocate wasm pages, to skip memset. Disable vfree. Fix build Revert mmap experiment

Don't use sbrk to load small files into the heap

44fc458

Use sbrk instead of mmap for dlmalloc on wasm

6911d37

Fix build

Revert "Use sbrk instead of mmap for dlmalloc on wasm"

7bd8b46

This reverts commit 0024b82.

kg force-pushed the wasm-sbrk branch from 34ed5c4 to 7bd8b46 Compare March 27, 2024 17:32

kg merged commit 001d60a into dotnet:main Apr 9, 2024
31 of 36 checks passed

github-actions bot locked and limited conversation to collaborators May 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap #100106

[wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap #100106

kg commented Mar 21, 2024 •

edited

Loading

dotnet-policy-service bot commented Mar 21, 2024

kg commented Mar 22, 2024

azure-pipelines bot commented Mar 22, 2024

kg commented Mar 22, 2024

SingleAccretion commented Mar 25, 2024 •

edited

Loading

kg commented Mar 25, 2024 •

edited

Loading

kg commented Mar 27, 2024

kg commented Mar 27, 2024

pavelsavara commented Apr 2, 2024

pavelsavara commented Apr 9, 2024

kg commented Apr 9, 2024

[wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap #100106

[wasm] use sbrk instead of emscripten mmap or malloc when loading bytes into heap #100106

Conversation

kg commented Mar 21, 2024 • edited Loading

dotnet-policy-service bot commented Mar 21, 2024

kg commented Mar 22, 2024

azure-pipelines bot commented Mar 22, 2024

kg commented Mar 22, 2024

SingleAccretion commented Mar 25, 2024 • edited Loading

kg commented Mar 25, 2024 • edited Loading

kg commented Mar 27, 2024

kg commented Mar 27, 2024

pavelsavara commented Apr 2, 2024

pavelsavara commented Apr 9, 2024

kg commented Apr 9, 2024

kg commented Mar 21, 2024 •

edited

Loading

SingleAccretion commented Mar 25, 2024 •

edited

Loading

kg commented Mar 25, 2024 •

edited

Loading