Compile dart2wasm modules using the JS runtime exported compileStreaming

[osa1]

With dart-lang/sdk@44c2e17 dart2wasm started using the new Wasm built-in string import wasm:js-string.

With dart-lang/sdk@4cd6096 dart2wasm started exporting compile and compileStreaming from the generated JS runtime to compile dart2wasm-generated modules with the wasm:js-string built-in, polyfilling it when not available.

Update Wasm compilation code in Flutter to use compileStreaming from the JS runtime, enabling fast jwasm:js-string module when available.

[osa1]

@eyebrowsoffire is this code path tested on the CI?

On the CI stringBuiltinSupported will be false, locally can I run the tests that use this code with a custom Chrome with extra command line flags, so that I can test the case where stringBuiltinSupported is true? We need to run a recent Chrome with --js-flags=--experimental-wasm-imported-strings for that variable to be true.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[mkustermann]

Please also wait for @eyebrowsoffire

[mkustermann]

We may consider in the future to make the .mjs file export 3 things:

• (new) Compile API wrapping WebAssembly.compile*
• Instantiate API wrapping WebAssembly.instantiate* (we already provide this)
• Invoke main API (we already provide this)

That would encapsulate this logic here in the dart2wasm compiler instead of making a user of the compiler aware of what builtins the compiled code requires.

There's an aspect to think about: The current way allows flutter JS code to be loaded in parallel to the mjs file, then we'd have a dependency from former to the latter - which may harm startup latency. This may especially be noticeable if we use imported strings (which may make the mjs file much bigger). So we'd have to think whether it would make sense to do that or not.

Anyways, that's not needed right now.

[osa1]

Why do you want separate compilation and instantiation steps? Currently we don't do anything with the compiled module other than instantiating it. We could combine both steps in a single export.

[mkustermann]

We can also offer this in the mjs api:

• (new) Compile&Instantiate API wrapping WebAssembly.compile* and WebAssembly.instantiate*

The setup should be optimized for startup time / initial page load. So we should try to do as much in parallel we can. So one advantage of separating the two, is that it allows the browser to download the wasm file & do some work in the streaming compile step in parallel to downloading/parsing/running the mjs file (which may become bigger once we have imported strings).

I don't know if Chrome/V8 does a lot of work in the compile step or most in instantiation step. May also differ between browsers.

This would need to be measured.

[osa1]

So one advantage of separating the two, is that it allows the browser to download the wasm file & do some work in the streaming compile step in parallel to downloading/parsing/running the mjs file (which may become bigger once we have imported strings).

If the compile function is provided by the mjs file so you can't compile the Wasm and download mjs file with lots of strings in parallel, right?

Maybe strings can be in a separate file that we download in parallel.

[goderbauer]

(triage): I spoke to @eyebrowsoffire and he said he is going to take a look at this one soon.

[eyebrowsoffire]

Sorry this took a million years for me to actually review. LGTM for now. I do think, as Martin suggests, some of this logic should be built into the .mjs file rather than done in the flutter bootstrapping code, but I think this works in the meantime.

[osa1]

I'm moving the compilation logic to the generated runtime blob in https://dart-review.googlesource.com/c/sdk/+/381581.

I'll get back to this once that's merged and rolled into the engine.

[osa1]

CI is failing with unrelated macos issue. Should we merge this? @mkustermann @eyebrowsoffire

[eyebrowsoffire]

CI is failing with unrelated macos issue. Should we merge this? @mkustermann @eyebrowsoffire

I reran the CI step and it passed, so I think we're good to go!