[browser] load core assemblies first

[pavelsavara]

start MonoVM when essential DLLs are downloaded and continue downloading the rest of the assets

• System.Private.CoreLib
• System.Collections
• System.Runtime.InteropServices.JavaScript
• runtimeconfig.bin
• dotnet.native.js.symbols if present

I estimate that this could shave 50ms from cold start.

other changes

• fix virtualWorkingDirectory
• make assets relative to / when not absolute
• when only config.assets

Resurrection of https://github.com/dotnet/runtime/pull/93480

[dotnet-policy-service[bot]]

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

[lambdageek]

@kg this is close to what you've been thinking about recently

[kg]

thanks for doing the hard work on this! i agree on your estimated startup reduction, should be a win

[pavelsavara]

we may need runtimeconfig.bin to be loaded into VFS before we start mono. And I'm not sure about ICU data.

[kg]

we may need runtimeconfig.bin to be loaded into VFS before we start mono. And I'm not sure about ICU data.

ICU data will only be needed if any runtime startup loads it. JS interop does with an accidental string operation right now. We could probably make it assert if there's an attempt to load ICU during this warming phase

[lewing]

I'm not sure if my recollection is correct but I think we explicitly load the icu data earlier than we need to as well. It might be worth exploring if we can delay it longer.

[pavelsavara]

I'm not sure if my recollection is correct but I think we explicitly load the icu data earlier than we need to as well. It might be worth exploring if we can delay it longer.

This currently postpones all but core DLLs

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

Right now, this PR is not AOT friendly because AOT assumes that metadata would be available for all images.

[pavelsavara]

we need System.Threading.Channels to be part of the core for MT build. @maraf

[pavelsavara]

Current CI fails with

[20:31:58] fail: [0x0118c038-dpty 20:31:58.466] MONO_WASM: start_runtime() failed {}

There is mono_runtime_class_init_full on stack for most of them.

[maraf]

We need to land this after https://github.com/dotnet/sdk/pull/39689

[pavelsavara]

we need to make ICU data "core" when the globalizationMode not invariant

[pavelsavara]

we need System.Threading.Channels to be part of the core for MT build. @maraf

with the last change maybe not. I need to try without.

[pavelsavara]

hmm, Log

[13:54:11] fail: Error in mono_download_assets: RangeError: Start offset -1 is outside the bounds of the buffer
[13:54:11] fail: [--000eafbc-emsc 13:54:11.333] MONO_WASM: Start offset -1 is outside the bounds of the buffer
                 RangeError: Start offset -1 is outside the bounds of the buffer
                     at new Uint8Array (<anonymous>)
                     at http://127.0.0.1:41625/_framework/dotnet.runtime.js:3:77638
                     at Object.pa [as instantiate_asset] (http://127.0.0.1:41625/_framework/dotnet.runtime.js:3:77686)
                     at n (http://127.0.0.1:41625/_framework/dotnet.js:3:8629)
                     at async Promise.all (index 129)
[13:54:11] fail: [out of order message from the browser]: http://127.0.0.1:41625/_framework/dotnet.runtime.js 2:77637 Uncaught RangeError: Start offset -1 is outside the bounds of the buffer
[13:54:11] info: WASM EXIT 1

[pavelsavara]

Above fail is ICU asset data being loaded into memory via mono_wasm_load_bytes_into_heap_persistent on MT build in UI thread, while the mono is starting on deputy thread.

It seems that Module._sbrk returned -1 🤯

@kg @lewing ideas ?

See also https://github.com/emscripten-core/emscripten/pull/20793/files

[kg]

Maybe we should just retry if it returns -1 in MT builds? We may have just lost some sort of race. I'm surprised this is possible though, and it would suggest that malloc can fail if we're unlucky too.

[pavelsavara]

It's kind of unrelated to this PR I moved the discussion to https://github.com/dotnet/runtime/issues/96546#issuecomment-2065933037

[pavelsavara]

@maraf this is now unblocked, right ?

[maraf]

@maraf this is now unblocked, right ?

Yes, once https://github.com/dotnet/sdk/pull/39689 flows through installer and we get updated installer dependency for WBT

[maraf]

• make assets relative to / when not absolute

Related https://github.com/dotnet/runtime/issues/99539

[maraf]

This is now unblocked in SDK

[pavelsavara]

I filled https://github.com/dotnet/runtime/issues/102196 and https://github.com/dotnet/runtime/issues/102195

[pavelsavara]

I filled https://github.com/dotnet/runtime/issues/102251

[pavelsavara]

/ba-g all issues are known

[pavelsavara]

60ms for firefox and 30ms for chrome during the cold start.