Intent to Ship: JavaScript BigInt to WebAssembly i64 integration

[Andreas Haas]

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.

[Andreas Haas]

Launch bug:  https://bugs.chromium.org/p/chromium/issues/detail?id=1094837  

[Andreas Haas]

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:

Spec

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

Contact emails

ah...@google.com, ecmzi...@google.com 

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.

--
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]

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:

Spec

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

Contact emails

ah...@google.com, ecmzi...@google.com 

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]

Thank you very much!

On Thu, Jun 18, 2020 at 9:22 PM <sligh...@chromium.org> wrote:

LGTM3

On Thursday, June 18, 2020 at 12:17:52 PM UTC-7, Mike West wrote:

LGTM2.

[Andreas Haas]

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