Intent to Extend Experiment: JavaScript Promise Integration

[Francis McCabe]

Contact emails

f...@chromium.org

Explainer

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Specification

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Design docs

https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#heading=h.n1atlriavj6v

Summary

Stack Switching denotes a technology that allows programs to suspend and resume computation. This is an active area that is part of the WebAssembly standards track. See https://github.com/WebAssembly/stack-switching and https://github.com/WebAssembly/meetings/tree/main/stack. This particular feature refers to the integration between JavaScript Promises and stack switching. This is described in more detail in https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#

Blink component

Blink>JavaScript>WebAssembly

Search tags

stack switching, Promise, JSPI

TAG review

https://github.com/w3ctag/design-reviews/issues/809

TAG review status

Pending

Chromium Trial Name

WebAssemblyJSPromiseIntegration

Origin Trial documentation link

https://github.com/WebAssembly/js-promise-integration

WebFeature UseCounter name

kV8WasmJavaScriptPromiseIntegration

Risks

Interoperability and Compatibility

This spec is backed by a standardization effort. We do not plan to ship the JSPI until it has been standardized by the W3C Wasm WG. However, post standardization, we will depend on all browsers implementing the standard.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627) Mozilla have started their own imlementation

WebKit: No signal

Web developers: No signals

Other signals:

Activation

Making use of JSPI requires some changes by WebAssembly-based developers (no impact on JavaScript developers). Depending on their toolchain usage a developer will need to modify their code. For Emscripten users, this is likely to be minimal as support for JSPI exists in Emscripten.

Security

1. Control flow integrity. 2. Ensuring that JavaScript programs cannot suspend via JSPI.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Goals for experimentation

Reason this experiment is being extended

JSPI is part of a standards track effort. We are currently in 'stage 3' of a five stage process. The next stage (4) is when a specification is deemed final. There was a change in the API which we soft launched in M126 but we would like to formally switch to this new API in M129. (We had informed our users that we would be maintaining the old API through the end of the OT.) So, in summary there are two reasons for extending the origin trial: 1. We are not quite ready to move the spec to phase 4. This is for non-implementation reasons: we need to draft and review the specification text. 2. We would like to allow sufficient time for users to fully experiment with the new API. We anticipate being able to fully ship JSPI before the end of 2024, but also dont want to have to ask for yet another extension.

Ongoing technical constraints

None.

Debuggability

Developers can piggyback on existing DevTools support for Promises to help with debugging JSPI applications. In particular the existing mechanisms for constructing extended stack traces from so-called Promise chains will also include stack traces from JSPI applications.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Partially

Flag name on chrome://flags

enable-experimental-webassembly-stack-switching

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2

Estimated milestones

Origin trial desktop first	123
Origin trial desktop last	128
Origin trial extension 1 end milestone	134
DevTrial on desktop	109

OriginTrial Android last	128
OriginTrial Android first	123

OriginTrial webView last	128
OriginTrial webView first	123

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5674874568704000?gate=5078038869180416

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Fu79zrp7MoE

This intent message was generated by Chrome Platform Status.

[Rick Byers]

Hi Francis,

We only do OT extensions for 3 milestones at a time. It sounds like there's been a meaningful change in the API that we need to validate, so extending for another 3 to 131 sounds OK to me if you'd like to do that, but that gets you only to October.

Outside of JS / WASM features, we generally do not block on standards maturity when shipping new APIs, since the chromium project has a policy of limiting the cost on velocity that we're willing to pay in order to reach standards consensus. What do you think the harm would be in shipping this now and coming up with a versioning and/or breaking change strategy for any changes which are deemed necessary after that? It sounds like you already have customers relying on this feature (given the commitments you mention around evolution of the API while in OT), so it's unclear whether shipping and iterating would really be all that different in practice?

Thanks,

   Rick

--
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/CAE65UWBDn_Vvj5uqqOVMABJWopy_ZfOz4P5ZZYiqCxa7HACxCA%40mail.gmail.com.

[Francis McCabe]

I am 'ok' with a shorter extension. I asked for 6 months because I foresee a reasonable risk of needing more than 3 milestones.

I am not 'ok' with shipping without the imprimatur of progress in the standardization. We recently did ship a phase 3 standard -- exceptions -- that turned out to be a mistake. It is likely going to be many years before that can be fully unwound.

 To be clear: I do not anticipate any issues with the standard; but then, no-one does.

Francis

[Alex Russell]

Like Rick, I'm also unsure why this isn't an I2S for the new design. Are y'all really unsure that the latest iteration has open issues that need resolution before shipping? Is there an minimum-viable subset you can ship now while extensions are debated behind another OT?

Best,

Alex

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46b78c6b-ae44-49ab-919c-3bd2194314f1n%40chromium.org.

[Francis McCabe]

The new API is actually a simplification of the 'old' API. It is not a question of base+extensions.

Note: the API design itself is gated by the WebAssembly stacks sub-group of the W3C community group.

[Deepti Gandluri]

On Mon, Jun 24, 2024 at 12:47 PM Rick Byers <rby...@chromium.org> wrote:

Hi Francis,

We only do OT extensions for 3 milestones at a time. It sounds like there's been a meaningful change in the API that we need to validate, so extending for another 3 to 131 sounds OK to me if you'd like to do that, but that gets you only to October.

Outside of JS / WASM features, we generally do not block on standards maturity when shipping new APIs, since the chromium project has a policy of limiting the cost on velocity that we're willing to pay in order to reach standards consensus. What do you think the harm would be in shipping this now and coming up with a versioning and/or breaking change strategy for any changes which are deemed necessary after that? It sounds like you already have customers relying on this feature (given the commitments you mention around evolution of the API while in OT), so it's unclear whether shipping and iterating would really be all that different in practice?

Apart from the API churn, the one requirement that we're missing for Phase 4 from the Wasm phases process is the spec document. The Wasm CG has a high level of consensus for this feature, and while a reasonably complete overview exists, a full spec of the feature does seem like a reasonable requirement to block on (IIUC for JSPI the other requirements have already been met, or should be non-controversial). 

On the implementation front, there are a couple of upcoming changes to improve performance that introduce significant code churn. Having the OT extended even for a shorter duration would mean that we're able to validate performance for current JSPI users, and get better bake time for fuzzer coverage before shipping. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9Kte1WKJVzPpMsnPMOj0vfBhqJ9XjiVi%3DNYyDm2TWy5g%40mail.gmail.com.

[Chris Harrelson]

LGTM to experiment for 3 more milestones.

Also: I asked Francis offline about the "soft launch in 126", and he clarified that it means we currently support both the new and promise integration APIs in the OT (which is possible because they happen not to have namespace collisions), so that OT participants can continue to finish testing on the first before migrating to the second. He also clarified that experimental feedback so far has demonstrated performance problems that led to improvements to the API and implementation.

It makes sense to me that we should extend the experiment 3 more milestones to provide time to test the newer API introduced in M126.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK-JJNTYSeNdSuai827Qg5%3D2vZo-emYP2z-5vJOfE%2B8Nng%40mail.gmail.com.