Support WebAssembly.instantiateStreaming

I think it's better support WebAssembly.instantiateStreaming.
It makes more easy to use WebAssembly and we can get more compatibility for Web.

It already implemented in Google Chrome, Firefox and some browsers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming

instantiateStreaming already exists in deps/v8/src/wasm/wasm-js.cc but cannot cover this branch.

node/deps/v8/src/wasm/wasm-js.cc

Lines 1177 to 1182 in de73272

    
           if (isolate->wasm_compile_streaming_callback() != nullptr) { 
        
             InstallFunc(isolate, webassembly, "compileStreaming", 
        
                         WebAssemblyCompileStreaming, 1); 
        
             InstallFunc(isolate, webassembly, "instantiateStreaming", 
        
                         WebAssemblyInstantiateStreaming, 1); 
        
           }

To cover this branch, we must call SetWasmCompileStreamingCallback.

node/deps/v8/include/v8.h

Line 7805 in de73272

void SetWasmCompileStreamingCallback(ApiImplementationCallback callback);

node/deps/v8/src/api.cc

Lines 8876 to 8877 in de73272

    
           CALLBACK_SETTER(WasmCompileStreamingCallback, ApiImplementationCallback, 
        
                           wasm_compile_streaming_callback)

In chromium, implemented here:
https://github.com/chromium/chromium/blob/51459d663d841c6430747aec97be9f7e7a7ca41f/third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc#L194-L222
And use it here:
https://github.com/chromium/chromium/blob/51459d663d841c6430747aec97be9f7e7a7ca41f/third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc#L228

Why we must inject the actual implementation,
It's said that this is for layering reasons.
WebAssembly/design#1085

Discussion

How about it?
How to make instantiateStreaming compatible with design.
- ex. instantiateStreaming(fs.promises.readFile('./some.wasm'), importObject)
  - It's not compatible with design.
  - readFile returns Buffer, not ArrayBuffer.

The design of instantiateStreaming currently requires Response to perform proper checks for stuff like mimes and whatnot. While node could implement instantiateStreaming possibly taking a node Stream object i don't think its worth splintering the wasm api between browsers and node. For some reasons i won't go into here node might gain a Response object anyway (and we're already working on mimes over in #21128) so once we get that stuff in this could be done.

While I understand that implementing WebAssembly for isomorphism might be good, but, for native modules, we already have Native and N-API addons. This would just be throwing another one into the mix.

@AyushG3112

@AyushG3112 we already support wasm, this would just be adding another method of loading it.

@devsnek

@devsnek ah, I did not know that. Nevermind my comment then, and thanks!

@devsnek

What is the use case besides feature parity with browsers? WebAssembly.instantiateStreaming() seems of limited usefulness in Node.js. Likewise WebAssembly.compileStreaming().

ex. instantiateStreaming(fs.promises.readFile('./some.wasm'), importObject)

That would be fairly straightforward to implement but I share @devsnek's sentiment that we shouldn't diverge from browsers lightly.

For some reasons i won't go into here node might gain a Response object

Pray tell!

@devsnek

@devsnek @bnoordhuis I totally agree.
I think it should be implemented the same API as browser.

Okay, but can you speak to your use case? As I said, I don't really see when or why you'd use it with Node.js.

@bnoordhuis

@bnoordhuis My use case is image processor what work on browser and Node.js implemented by WebAssembly.
And small wrapper for loading it.

BTW, I think we decide to implement Fetch API or not prior to start this discussion.
It already discussing in this issue: #19393 (comment)

image processor what work on browser and Node.js implemented by WebAssembly

I can see why you'd load it in streaming fashion in a browser but why in Node.js? If it's an on-disk file, just load it in one go.

@bnoordhuis

@bnoordhuis
Personally, The most important reason is portability.
I want to use instantiateStreaming because Google recommended way of loading WebAssembly to use WebAssembly.*Streaming.
But cannot use instantiateStreaming if planned to run both Node.js and browser.

@bmeck

What if the WebAssembly loading and instantiation is done is a separate worker and posted to the main thread?

Also FYI https://github.com/wasm-tool/node-loader. I know that @bmeck is working a multi-threaded loading which would fit well to this use case.

👀

lib,src: implement WebAssembly Web API

Navigation Menu

Repository navigation

Support WebAssembly.instantiateStreaming #21130

Discussion

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if (isolate->wasm_compile_streaming_callback() != nullptr) {
	InstallFunc(isolate, webassembly, "compileStreaming",
	WebAssemblyCompileStreaming, 1);
	InstallFunc(isolate, webassembly, "instantiateStreaming",
	WebAssemblyInstantiateStreaming, 1);
	}

	CALLBACK_SETTER(WasmCompileStreamingCallback, ApiImplementationCallback,
	wasm_compile_streaming_callback)

Support WebAssembly.instantiateStreaming #21130

Description

Discussion

Activity

devsnek commented on Jun 5, 2018

AyushG3112 commented on Jun 5, 2018

devsnek commented on Jun 5, 2018

AyushG3112 commented on Jun 5, 2018

bnoordhuis commented on Jun 5, 2018

Leko commented on Jun 5, 2018

bnoordhuis commented on Jun 5, 2018

Leko commented on Jun 5, 2018

bnoordhuis commented on Jun 5, 2018

Leko commented on Jun 7, 2018

xtuc commented on Jun 26, 2018

11 remaining items

devsnek commented on Apr 12, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions