[wasm] introduce response-based compile & instantiate APIs |
|||
Issue descriptionPlease refer to https://github.com/WebAssembly/design/pull/991, and then to https://github.com/WebAssembly/design/blob/master/Web.md#additional-web-embedding-api for the specification. The motivation for these APIs is: - enabling streamed compilation of wasm modules. Compilation of large modules, as found in games, takes a considerable amount of time, which negatively impacts user experience through a perceived large load time. This can be mitigated by masking the compilation time with the download time, by performing compilation while downloading - allows tracking of origin of wasm module (compiled or raw bytes) - unblocks caching API - based solutions for avoiding recompilation
,
Mar 29 2017
I have a prototype "compile" https://codereview.chromium.org/2780693003/ I need to figure out how to initialize the overloading hooks without breaking layering.
,
Apr 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/0bd9f1b8e60466fcfbbb01b5d048c72e3d01d361 commit 0bd9f1b8e60466fcfbbb01b5d048c72e3d01d361 Author: mtrofin <mtrofin@chromium.org> Date: Tue Apr 04 16:22:46 2017 [wasm] Module Builder v8 API: bytes passed in are owned by caller. This reflects both the contract in blink, as well as what we plan to do in streamed compilation, where we'll want to lay out bytes received such that each section and each function body is contiguous, but they may all be separate - which entails a copy. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2797653002 Cr-Commit-Position: refs/heads/master@{#44387} [modify] https://crrev.com/0bd9f1b8e60466fcfbbb01b5d048c72e3d01d361/include/v8.h [modify] https://crrev.com/0bd9f1b8e60466fcfbbb01b5d048c72e3d01d361/src/api.cc [modify] https://crrev.com/0bd9f1b8e60466fcfbbb01b5d048c72e3d01d361/test/cctest/wasm/test-run-wasm-module.cc
,
Apr 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/380bc71f286663403e7706aedcf66f724c89b584 commit 380bc71f286663403e7706aedcf66f724c89b584 Author: mtrofin <mtrofin@chromium.org> Date: Fri Apr 07 17:49:51 2017 [wasm] response-based compile APIs Spec available at: https://github.com/WebAssembly/design/blob/master/Web.md#webassemblycompile This CL introduces the WebAssembly.compile overload in Blink. Notably, we do not currently check the mime type (chromium:707149). The V8 side is still under development. We currently exercise a skeleton API with a trivial implementation. Once the full implementation is implemented, we will enhance the blink side of the feature - for instance, we can introduce back pressure information. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2780693003 Cr-Commit-Position: refs/heads/master@{#462917} [add] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/LayoutTests/http/tests/wasm/wasm_response_apis.html [add] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/LayoutTests/http/tests/wasm/wasm_response_apis.js [modify] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/bindings/modules/v8/ModuleBindingsInitializer.cpp [modify] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/bindings/modules/v8/v8.gni [add] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/bindings/modules/v8/wasm/WasmResponseExtensions.cpp [add] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/bindings/modules/v8/wasm/WasmResponseExtensions.h [modify] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/modules/fetch/BodyStreamBuffer.cpp [modify] https://crrev.com/380bc71f286663403e7706aedcf66f724c89b584/third_party/WebKit/Source/modules/fetch/FetchDataLoader.h
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb commit 7829af3275ff4644a2d0a1270abe1a1e4415e9fb Author: mtrofin <mtrofin@chromium.org> Date: Wed Apr 12 00:01:04 2017 [wasm] instantiate expressed in terms of compile Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44592} [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime-test.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-js.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/instantiate-run-basic.js [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/js-api.js [add] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/wasm-api-overloading.js
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb commit 7829af3275ff4644a2d0a1270abe1a1e4415e9fb Author: mtrofin <mtrofin@chromium.org> Date: Wed Apr 12 00:01:04 2017 [wasm] instantiate expressed in terms of compile Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44592} [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime-test.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-js.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/instantiate-run-basic.js [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/js-api.js [add] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/wasm-api-overloading.js
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb commit 7829af3275ff4644a2d0a1270abe1a1e4415e9fb Author: mtrofin <mtrofin@chromium.org> Date: Wed Apr 12 00:01:04 2017 [wasm] instantiate expressed in terms of compile Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44592} [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime-test.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/runtime/runtime.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-js.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.cc [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/src/wasm/wasm-module.h [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/instantiate-run-basic.js [modify] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/js-api.js [add] https://crrev.com/7829af3275ff4644a2d0a1270abe1a1e4415e9fb/test/mjsunit/wasm/wasm-api-overloading.js
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a commit d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a Author: hablich <hablich@chromium.org> Date: Wed Apr 12 13:27:56 2017 Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ ) Reason for revert: Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824 Original issue's description: > [wasm] instantiate expressed in terms of compile > > Today, the semantics of: > > WebAssembly.instantiate > > and > > WebAssembly.compile().then(new WebAssemblyInstance) > > are subtly different, to the point where attempting the proposed > change uncovered bugs. > > In the future, it's possible that .instantiate actually have different > semantics - if we pre-specialized to the provided ffi, for example. > Right now that's not the case. > > This CL: > - gets our implementation closer to what developers may write using > the compile -> new Instance alternative, in particular wrt promise > creation. By reusing code paths, we uncover more bugs, and keep > maintenance cost lower. > > - it gives us the response-based WebAssembly.instantiate implicitly. > Otherwise, we'd need that same implementation on the blink side. The > negative is maintenance: imagine if the bugs I mentioned could only be > found when running in Blink. > > BUG= chromium:697028 > > Review-Url: https://codereview.chromium.org/2806073002 > Cr-Commit-Position: refs/heads/master@{#44592} > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2810203002 Cr-Commit-Position: refs/heads/master@{#44614} [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/src/runtime/runtime-test.cc [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/src/runtime/runtime.h [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/src/wasm/wasm-js.cc [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/src/wasm/wasm-module.cc [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/src/wasm/wasm-module.h [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/test/mjsunit/wasm/instantiate-run-basic.js [modify] https://crrev.com/d3f1d5c50cd6ada48371c1eb2560d2b0ec24533a/test/mjsunit/wasm/js-api.js [delete] https://crrev.com/7ad0742799e3f48e35faf8c66810d478bbce66b6/test/mjsunit/wasm/wasm-api-overloading.js
,
Apr 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/71cf4890d0a2bc3ac47597d724676df871a572d5 commit 71cf4890d0a2bc3ac47597d724676df871a572d5 Author: mtrofin <mtrofin@chromium.org> Date: Tue Apr 18 01:31:16 2017 [wasm] instantiate expressed in terms of compile Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Original-Commit-Position: refs/heads/master@{#44592} Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44669} [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/src/runtime/runtime-test.cc [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/src/runtime/runtime.h [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/src/wasm/wasm-js.cc [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/src/wasm/wasm-module.cc [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/src/wasm/wasm-module.h [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/test/mjsunit/wasm/instantiate-run-basic.js [modify] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/test/mjsunit/wasm/js-api.js [add] https://crrev.com/71cf4890d0a2bc3ac47597d724676df871a572d5/test/mjsunit/wasm/wasm-api-overloading.js
,
Apr 18 2017
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5e246838263416bcd05bf1b10c6c4d8582681a5a commit 5e246838263416bcd05bf1b10c6c4d8582681a5a Author: mtrofin <mtrofin@chromium.org> Date: Thu Apr 20 22:53:42 2017 [wasm] Tests for Response instantiate APIs BUG= chromium:697028 Review-Url: https://codereview.chromium.org/2826283003 Cr-Commit-Position: refs/heads/master@{#466174} [add] https://crrev.com/5e246838263416bcd05bf1b10c6c4d8582681a5a/third_party/WebKit/LayoutTests/http/tests/wasm/resources/wasm-constants.js [add] https://crrev.com/5e246838263416bcd05bf1b10c6c4d8582681a5a/third_party/WebKit/LayoutTests/http/tests/wasm/resources/wasm-module-builder.js [modify] https://crrev.com/5e246838263416bcd05bf1b10c6c4d8582681a5a/third_party/WebKit/LayoutTests/http/tests/wasm_streaming/wasm_response_apis.html [modify] https://crrev.com/5e246838263416bcd05bf1b10c6c4d8582681a5a/third_party/WebKit/LayoutTests/http/tests/wasm_streaming/wasm_response_apis.js |
|||
►
Sign in to add a comment |
|||
Comment 1 by bugdroid1@chromium.org
, Mar 23 2017