Intent to Ship: JavaScript BigInt to WebAssembly i64 integration

169 views
Skip to first unread message

Andreas Haas

unread,
Jun 12, 2020, 2:42:11 AM6/12/20
to blin...@chromium.org, v8-u...@googlegroups.com

Spec

https://github.com/WebAssembly/JS-BigInt-integration  

Contact emails
ah...@google.com, ecmzi...@google.com 

Summary

The "JavaScript BigInt to WebAssembly i64 integration" proposal extends the JavaScript-WebAssembly API to allow passing I64  values from WebAssembly to JavaScript, and vice versa. The representation of I64 values in JavaScript is BigInt.

Without this proposal, an exception is thrown every time an I64 value is passed over the WebAssembly - JavaScript API.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? 

Yes. 

Interoperability and Compatibility risk

This is a finished WebAssembly proposal and has already been integrated into the core WebAssembly spec. The proposal is implemented in Chrome and Firefox and passes the spec tests in both. Changing the proposal would require changing the WebAssembly spec.

Firefox: Implemented
Safari: No signals

Is this feature fully tested?

Yes, tested in wasm mjsunit tests:

https://cs.chromium.org/chromium/src/v8/test/mjsunit/wasm/bigint.js


Also passes the wasm spec tests: https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api


The feature has also been staged for several months now to get ClusterFuzz coverage.


Tracking bug

https://crbug.com/v8/7741

Entry on the feature dashboard

https://chromestatus.com/feature/5648655109324800  

Requesting approval to ship?

Yes.

Yoav Weiss

unread,
Jun 15, 2020, 6:52:07 AM6/15/20
to Andreas Haas, blink-dev, v8-users
On Fri, Jun 12, 2020 at 8:42 AM 'Andreas Haas' via blink-dev <blin...@chromium.org> wrote:

I'm missing an explainer and a TAG review from the template. 
While a TAG review is probably not relevant for WASM changes, it might be worthwhile to mention that, and cover whatever broad review this feature have received from the relevant folks.

Summary

The "JavaScript BigInt to WebAssembly i64 integration" proposal extends the JavaScript-WebAssembly API to allow passing I64  values from WebAssembly to JavaScript, and vice versa. The representation of I64 values in JavaScript is BigInt.

Without this proposal, an exception is thrown every time an I64 value is passed over the WebAssembly - JavaScript API.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? 

Yes. 

Interoperability and Compatibility risk

This is a finished WebAssembly proposal and has already been integrated into the core WebAssembly spec. The proposal is implemented in Chrome and Firefox and passes the spec tests in both. Changing the proposal would require changing the WebAssembly spec.
 
Regardless of spec status:
  • How likely is shipping this to break existing WASM content?
  • What happens if WASM content that contains BigInt is served to non-supporting browsers?
  • Assuming the answer to the above question is "something bad", how are developers supposed to know to serve this feature only to supporting browsers? Feature detection? UA sniffing? Other?


Firefox: Implemented
 
And shipped? 

Safari: No signals

Have we reached out? 

Is this feature fully tested?

Yes, tested in wasm mjsunit tests:

https://cs.chromium.org/chromium/src/v8/test/mjsunit/wasm/bigint.js


Also passes the wasm spec tests: https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api


Are there WPTs?
 


The feature has also been staged for several months now to get ClusterFuzz coverage.


Tracking bug

https://crbug.com/v8/7741

Entry on the feature dashboard

https://chromestatus.com/feature/5648655109324800  

Requesting approval to ship?

Yes.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvf%3DT2c44y-3-koKda%3Dbpd40%2BoYbq92p7c2v6jdjoMR05A%40mail.gmail.com.

Yoav Weiss

unread,
Jun 16, 2020, 7:59:42 AM6/16/20
to Andreas Haas, blink-dev, v8-users
LGTM1

On Tue, Jun 16, 2020 at 10:16 AM Andreas Haas <ah...@chromium.org> wrote:


On Mon, Jun 15, 2020 at 12:52 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jun 12, 2020 at 8:42 AM 'Andreas Haas' via blink-dev <blin...@chromium.org> wrote:

I'm missing an explainer and a TAG review from the template. 
While a TAG review is probably not relevant for WASM changes, it might be worthwhile to mention that, and cover whatever broad review this feature have received from the relevant folks.

Our process says that a TAG review is not required, as this is just a small extension to WebAssembly, and the Wasm CG already provides significant technical oversight.

The explainer in https://github.com/WebAssembly/JS-BigInt-integration is a bit short, because it's such a natural extension. When the first WebAssembly spec was made, the BigInt spec was not completed yet. Therefore there did not exist a type in JavaScript that could store WebAssembly I64 values losslessly. It was decided back then that in the first version of WebAssembly, I64 values cannot be passed to JavaScript, and that a RuntimeError is thrown instead whenever it is done.
In the meantime the BigInt spec was completed, so JavaScript can now store I64 values losslessly. With this proposal, the WebAssembly spec got extended so that I64 values can be passed to JavaScript as BigInts, and vice versa.

Great, thanks!
 

Summary

The "JavaScript BigInt to WebAssembly i64 integration" proposal extends the JavaScript-WebAssembly API to allow passing I64  values from WebAssembly to JavaScript, and vice versa. The representation of I64 values in JavaScript is BigInt.

Without this proposal, an exception is thrown every time an I64 value is passed over the WebAssembly - JavaScript API.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? 

Yes. 

Interoperability and Compatibility risk

This is a finished WebAssembly proposal and has already been integrated into the core WebAssembly spec. The proposal is implemented in Chrome and Firefox and passes the spec tests in both. Changing the proposal would require changing the WebAssembly spec.
 
Regardless of spec status:
  • How likely is shipping this to break existing WASM content?
It is unlikely that shipping this will break existing WebAssembly content. With this feature it is possible to pass WebAssembly I64 values to JavaScript, which currently causes a RuntimeError. 
  • What happens if WASM content that contains BigInt is served to non-supporting browsers?
A RuntimeError is thrown. 
  • Assuming the answer to the above question is "something bad", how are developers supposed to know to serve this feature only to supporting browsers? Feature detection? UA sniffing? Other?
Feature detection is easily possible. 

That's great!
Do we expect WASM toolchains to use that? Do you know if they integrated that already?



Firefox: Implemented
 
Firefox ships this feature in Version 78, which is the current beta.

Safari: No signals

Have we reached out? 
I will try to get information about this. 

Would be great if you could file an issue.

 

Is this feature fully tested?

Yes, tested in wasm mjsunit tests:

https://cs.chromium.org/chromium/src/v8/test/mjsunit/wasm/bigint.js


Also passes the wasm spec tests: https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api


Are there WPTs?

Tests exist in the spec proposal, see https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api. The tests should get merged into WPT eventually, but as far as I can tell this has not happened yet. Our implementation passes all these tests.

OK

Andreas Haas

unread,
Jun 16, 2020, 11:53:15 AM6/16/20
to Yoav Weiss, blink-dev, v8-users
On Mon, Jun 15, 2020 at 12:52 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jun 12, 2020 at 8:42 AM 'Andreas Haas' via blink-dev <blin...@chromium.org> wrote:

I'm missing an explainer and a TAG review from the template. 
While a TAG review is probably not relevant for WASM changes, it might be worthwhile to mention that, and cover whatever broad review this feature have received from the relevant folks.

Our process says that a TAG review is not required, as this is just a small extension to WebAssembly, and the Wasm CG already provides significant technical oversight.

The explainer in https://github.com/WebAssembly/JS-BigInt-integration is a bit short, because it's such a natural extension. When the first WebAssembly spec was made, the BigInt spec was not completed yet. Therefore there did not exist a type in JavaScript that could store WebAssembly I64 values losslessly. It was decided back then that in the first version of WebAssembly, I64 values cannot be passed to JavaScript, and that a RuntimeError is thrown instead whenever it is done.
In the meantime the BigInt spec was completed, so JavaScript can now store I64 values losslessly. With this proposal, the WebAssembly spec got extended so that I64 values can be passed to JavaScript as BigInts, and vice versa.

Summary

The "JavaScript BigInt to WebAssembly i64 integration" proposal extends the JavaScript-WebAssembly API to allow passing I64  values from WebAssembly to JavaScript, and vice versa. The representation of I64 values in JavaScript is BigInt.

Without this proposal, an exception is thrown every time an I64 value is passed over the WebAssembly - JavaScript API.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? 

Yes. 

Interoperability and Compatibility risk

This is a finished WebAssembly proposal and has already been integrated into the core WebAssembly spec. The proposal is implemented in Chrome and Firefox and passes the spec tests in both. Changing the proposal would require changing the WebAssembly spec.
 
Regardless of spec status:
  • How likely is shipping this to break existing WASM content?
It is unlikely that shipping this will break existing WebAssembly content. With this feature it is possible to pass WebAssembly I64 values to JavaScript, which currently causes a RuntimeError. 
  • What happens if WASM content that contains BigInt is served to non-supporting browsers?
A RuntimeError is thrown. 
  • Assuming the answer to the above question is "something bad", how are developers supposed to know to serve this feature only to supporting browsers? Feature detection? UA sniffing? Other?
Feature detection is easily possible. 


Firefox: Implemented
 
Firefox ships this feature in Version 78, which is the current beta.

Safari: No signals

Have we reached out? 
I will try to get information about this. 
 

Is this feature fully tested?

Yes, tested in wasm mjsunit tests:

https://cs.chromium.org/chromium/src/v8/test/mjsunit/wasm/bigint.js


Also passes the wasm spec tests: https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api


Are there WPTs?

Tests exist in the spec proposal, see https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test/js-api. The tests should get merged into WPT eventually, but as far as I can tell this has not happened yet. Our implementation passes all these tests.

The feature has also been staged for several months now to get ClusterFuzz coverage.


Tracking bug

https://crbug.com/v8/7741

Entry on the feature dashboard

https://chromestatus.com/feature/5648655109324800  

Requesting approval to ship?

Yes.

Andreas Haas

unread,
Jun 16, 2020, 11:54:30 AM6/16/20
to blink-dev, Andreas Haas, v8-u...@googlegroups.com
Launch bug:  https://bugs.chromium.org/p/chromium/issues/detail?id=1094837  

Mike West

unread,
Jun 18, 2020, 3:17:52 PM6/18/20
to blink-dev, Andreas Haas, Andreas Haas, v8-u...@googlegroups.com
LGTM2.

sligh...@chromium.org

unread,
Jun 18, 2020, 3:22:33 PM6/18/20
to blink-dev, ah...@chromium.org, ah...@google.com, v8-u...@googlegroups.com
LGTM3

Derek Schuff

unread,
Jun 18, 2020, 7:15:22 PM6/18/20
to blink-dev, yo...@yoav.ws, blink-dev, v8-users, Andreas Haas


On Tuesday, June 16, 2020 at 4:59:42 AM UTC-7 yo...@yoav.ws wrote:
LGTM1
Feature detection is easily possible. 

That's great!
Do we expect WASM toolchains to use that? Do you know if they integrated that already?



Regarding the toolchain question:
Unfortunately this (along with most other wasm feature extensions) needs to be a compile-time option for emscripten because (for bigint) it affects the interface between the wasm code and the JS code that emscripten packages along with it.
Currently the best practice is to compile multiple packages, and then select which one to load based on feature detection. There exist several JS libraries for this purpose, one of which is written by our devrel folks. How to streamline this process is an area of active work in the toolchain and broader wasm team.
 

Andreas Haas

unread,
Jun 22, 2020, 2:49:49 AM6/22/20
to blink-dev, v8-users
Thank you very much!

Andreas Haas

unread,
Jun 24, 2020, 3:38:05 AM6/24/20
to blink-dev, v8-users
Hi,

I got a reply from Apple now. Here is the tracking bug, see https://bugs.webkit.org/show_bug.cgi?id=213528. It does not show any work yet.

Cheers,
Andreas
Reply all
Reply to author
Forward
0 new messages