Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Compile dart2wasm modules using the JS runtime exported compileStreaming #51488

Merged
osa1 merged 9 commits into from
Aug 28, 2024
Merged

Compile dart2wasm modules using the JS runtime exported compileStreaming #51488

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
a0a8805
Update dart2wasm module compilation to use Wasm string builtins
osa1 Mar 18, 2024
5ecec4a
Fix detectWasmStringBuiltin call
osa1 Mar 18, 2024
cc677af
Merge remote-tracking branch 'origin/main' into dart2wasm_string_buil…
osa1 Mar 19, 2024
8232d85
Remove polyfill, dart2wasm mjs file provides it
osa1 Mar 19, 2024
0789214
Revert whitespace
osa1 Mar 19, 2024
0ebfbf8
Merge remote-tracking branch 'origin/main' into dart2wasm_string_buil…
osa1 Aug 26, 2024
4d70159
Use compileStreaming from JS shim
osa1 Aug 26, 2024
4064581
Revert whitespace change
osa1 Aug 26, 2024
adac7ec
Merge branch 'main' into dart2wasm_string_builtins
osa1 Aug 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 35 additions & 1 deletion lib/web_ui/flutter_js/src/entrypoint_loader.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -151,7 +151,13 @@ export class FlutterEntrypointLoader {
if (this._ttPolicy != null) {
jsSupportRuntimeUri = this._ttPolicy.createScriptURL(jsSupportRuntimeUri);
}
const dartModulePromise = WebAssembly.compileStreaming(fetch(moduleUri));

const stringBuiltinSupported = _detectWasmStringBuiltin();

const dartModulePromise = WebAssembly.compileStreaming(
Copy link
Member

@mkustermann mkustermann Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@osa1 osa1 Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@mkustermann mkustermann Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@osa1 osa1 Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

fetch(moduleUri),
stringBuiltinSupported ? {builtins: 'js-string'} : {}
);

const jsSupportRuntime = await import(jsSupportRuntimeUri);

Expand All @@ -171,6 +177,23 @@ export class FlutterEntrypointLoader {
} else {
imports = {};
}

if (!stringBuiltinSupported) {
imports['wasm:js-string'] = {
"charCodeAt": (s, i) => s.charCodeAt(i),
"compare": (s1, s2) => {
if (s1 < s2) return -1;
if (s1 > s2) return 1;
return 0;
},
"concat": (s1, s2) => s1 + s2,
"equals": (s1, s2) => s1 === s2,
"fromCharCode": (i) => String.fromCharCode(i),
"length": (s) => s.length,
"substring": (s, a, b) => s.substring(a, b),
};
}

const moduleInstance = await jsSupportRuntime.instantiate(dartModulePromise, imports);
await jsSupportRuntime.invoke(moduleInstance);
}
Expand All @@ -195,4 +218,15 @@ export class FlutterEntrypointLoader {
scriptTag.src = trustedUrl;
return scriptTag;
}

/// Returns whether the `js-string` Wasm built-in is supported.
_detectWasmStringBuiltin() {
let bytes = [
0, 97, 115, 109, 1, 0, 0, 0, 1, 4, 1, 96, 0,
0, 2, 23, 1, 14, 119, 97, 115, 109, 58, 106, 115, 45,
115, 116, 114, 105, 110, 103, 4, 99, 97, 115, 116, 0, 0
];
return !WebAssembly.validate(
new Uint8Array(bytes), {builtins: ['js-string']});
}
}