Ship the JSPI kitchen-sink build to Chrome users

[adamziel]

Description

We use Asyncify to call asynchronous JavaScript functions from synchronous WebAssembly code.

However, Asyncify forces us to maintain a large list of all the C functions that can be at the call stack at the time of making an asynchronous call must be listed during the build. When we miss even one, that code path triggers a fatal crash ("unreachable" WASM instruction executed). People report those crashes rather often.

JSPI (proposal) is the new API that doesn't require maintaining that list and produces a smaller and faster binary.

Let's explore migrating to JSPI to solve these issues and more:

• WooCommerce crash #967
• Can’t place orders in Woo when HPOS is enabled #731
• PHP-WASM: improve phar support (Asyncify error – null function or function signature mismatch) #1241
• Curl extension for the Node.js build of PHP.wasm #1273
• Add PHP iterator and yield support #1181
• Fix shutdown errors #1104
• PHP: Add zif_array_filter to Asyncify list #397

Next steps

We have a PR adding JSPI Support. It works in Node.js v22 and Chrome – both require a feature flag or applying to an origin trial.

I don't expect stable JSPI support in all major runtimes (Chrome, Firefox, Safari, mobile browsers, last 3 Node versions) for the next year, two, or even three. I'm happy to be wrong here, but I didn't see any proof of imminent rollout.

Here's what we could do:

1. JSPI: Enable the origin trial on Chrome #1346
2. Adjust the PR to build both the Asyncify and JSPI versions of the kitchen sink bundle (but not of the light bundle to save on the build time)
3. Deploy both bundles to playground.wordpress.net
4. Ship the JSPI version to Chrome users, ship the Asyncify versions to everyone else
5. Keep the Node.js on Asyncify for the time being

This should get us:

• Less people experiencing Asyncify crashes
• An easy way to upgrade more users to JSPI as other browsers catch up

Runtime support as of April 29th, 2024

JSPI is supported on:

• ✅ Google Chrome with #enable-experimental-webassembly-jspi enabled at chrome://flags, or with sites where the JSPI origin trial is enabled.
• ✅ Node.js v22+ with --experimental-wasm-stack-switching feature flag.
• ✅ Firefox nightly
• ❌ Safari, older browsers
• ❌ Bun, Node.js <= 21
• ❔ I'm Not sure about Chrome-based browsers

[adamziel]

JSPI is available in Node.js behind the --experimental-wasm-stack-switching flag – thank you for sharing @fmgccabe!

Here's some notes I took to find that flag:

• Stack switching in V8
• Experimental flag in V8
• The same flag in Node.js
• --trace_wasm_stack_switching used in tests
• node --v8-options gives all v8-specific CLI options
• One of them is --experimental-wasm-stack-switching

It's available in Node 17, 18, 19, and 20. Node 16 exists with a bad option error message.

[adamziel]

Relevant:

• JS promise integration overview
• Stack Switching proposal

[adamziel]

I tried:

    -s ASYNCIFY=2
    -s ASYNCIFY_EXPORTS="$EXPORTED_FUNCTIONS" \
    -s ASYNCIFY_IMPORTS='["wasm_setsockopt","js_popen_to_file","wasm_socket_has_data","wasm_poll_socket","wasm_close","wasm_shutdown"]' \

(not all of these functions are needed but I just wanted to get something working)

And ran

nx build php-wasm-node
nx build wp-now
node --experimental-wasm-stack-switching  --loader=./packages/nx-extensions/src/executors/built-script/loader.mjs --stack-trace-limit=50 dist/packages/wp-now/main.js start --path=./plugin --php=7.4

And got this error:

TypeError: Cannot read properties of undefined (reading '0')
    at sigToWasmTypes (/playground/dist/packages/php-wasm/node/index.cjs:30939:19)
    at /playground/dist/packages/php-wasm/node/index.cjs:30959:26
    at Object.instrumentWasmImports (/playground/dist/packages/php-wasm/node/index.cjs:30966:11)
    at Object.init4 (/playground/dist/packages/php-wasm/node/index.cjs:31353:12)
    at loadPHPRuntime (/playground/dist/packages/php-wasm/node/index.cjs:67103:38)
    at doLoad (/playground/dist/packages/php-wasm/node/index.cjs:67997:31)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Function.load (/playground/dist/packages/php-wasm/node/index.cjs:67982:12)
    at async _WPNow.setup_fn (file:///playground/dist/packages/wp-now/main.js:350:14)
    at async Function.create (file:///playground/dist/packages/wp-now/main.js:204:5)
    at async startServer (file:///playground/dist/packages/wp-now/main.js:469:17)
    at async Object.handler (file:///playground/dist/packages/wp-now/main.js:569:9)

Turns out instrumentWasmImports generated by Emscripten could had no exports signatures stored. I did some monkeypatching and added this:

  var Asyncify = {
    instrumentWasmImports: function(imports) {
      // ...
            if (isAsyncifyImport) {
              if (x === 'js_popen_to_file') {
                sig = "iiii";
              } else if (x === 'wasm_close') {
                sig = "ii";
              } else if (x === 'wasm_shutdown') {
                sig = "iii";
              } else if (x === 'wasm_poll_socket') {
                sig = "iiii";
              } else if (x === 'wasm_setsockopt') {
                sig = "piiipii";
              }

And got one step further:

RuntimeError: null function or function signature mismatch
    at call (wasm://wasm/02952aa6:wasm-function[5683]:0x3f303a)
    at ret.<computed> (playground/dist/packages/php-wasm/node/index.cjs:30981:31)
    at Module.dynCall_v (playground/dist/packages/php-wasm/node/index.cjs:31527:75)
    at invoke_v (playground/dist/packages/php-wasm/node/index.cjs:31628:7)
    at invoke_v (wasm://wasm/02952aa6:wasm-function[371]:0x2bfad)
    at php_module_startup (wasm://wasm/02952aa6:wasm-function[5142]:0x390ac6)
    at wasm_sapi_module_startup (wasm://wasm/02952aa6:wasm-function[4570]:0x31b10b)
    at byn$fpcast-emu$wasm_sapi_module_startup (wasm://wasm/02952aa6:wasm-function[5725]:0x3f3cc9)
    at php_wasm_init (wasm://wasm/02952aa6:wasm-function[9870]:0x560402)
    at ret.<computed> (playground/dist/packages/php-wasm/node/index.cjs:30981:31)
    at Module._php_wasm_init (playground/dist/packages/php-wasm/node/index.cjs:31467:89)
    at Object.ccall (playground/dist/packages/php-wasm/node/index.cjs:31062:20)
    at _NodePHP.#initWebRuntime (playground/dist/packages/php-wasm/node/index.cjs:67350:32)
    at _NodePHP.run (playground/dist/packages/php-wasm/node/index.cjs:67315:27)
    at PHPRequestHandler.#dispatchToPHP (playground/dist/packages/php-wasm/node/index.cjs:66884:29)
    at async PHPRequestHandler.request (playground/dist/packages/php-wasm/node/index.cjs:66802:12)
    at async PHPBrowser.request (playground/dist/packages/php-wasm/node/index.cjs:66596:22)

Seems like an error in a dynamic call, so I added invoke_* to the list of wrapped imports:

            var isAsyncifyImport = ASYNCIFY_IMPORTS.indexOf(x2) >= 0
              || x2.startsWith("__asyncjs__")
              || x2.startsWith("invoke")
              ;
              if(x === 'invoke_viidii') {
                return; // I couldn't get this one right
              } else if(x.startsWith('invoke_v')) {
                sig = x.substr(7) + 'i';
              }

But I'm not sure if that was a good step, the error now is:

RuntimeError: invalid suspender object for suspend
    at invoke_v (wasm://wasm/02952aa6:wasm-function[371]:0x2bfad)
    at php_module_startup (wasm://wasm/02952aa6:wasm-function[5142]:0x390ac6)
    at wasm_sapi_module_startup (wasm://wasm/02952aa6:wasm-function[4570]:0x31b10b)
    at byn$fpcast-emu$wasm_sapi_module_startup (wasm://wasm/02952aa6:wasm-function[5725]:0x3f3cc9)
    at php_wasm_init (wasm://wasm/02952aa6:wasm-function[9870]:0x560402)
    ...

I am running on latest emsdk as of today, which wraps the imports in:

              imports[x2] = original = new WebAssembly.Function(type, original, {
                suspending: "first"
              });

And the exports in:

      return new WebAssembly.Function({
        parameters,
        results: ["externref"]
      }, original, {
        promising: "first"
      });

[adamziel]

I'm stuck at this point and the JSPI API is still experimental – let's revisit this once the API is stable.

[dmsnell]

@adamziel is there a short version of what ASYNCIFY_ONLY does? is it a macro that wraps those functions or rewrites them into some continuable state machine?

[adamziel]

@dmsnell pretty much yes – it rewrites these functions as a continuable state machine.

When the async call is made, it saves the call stack and sets a global flag to make all the functions on that call stack short-circuit. Then it synchronously returns.

When the async call is finished, it restores the call stack, sets other global flags, and continues right after the async call.

Note that we need to use ASYNCIFY_ONLY now when PHP is built with ASYNCIFY=1. This issue explores switching to a new experimental API called JSPI that is activated via ASYNCIFY=2. Thia naming is confusing as these are two completely different APIs. JSPI is smart about the call stack and only requires us to list asynchronous C-level imports and exports.

[adamziel]

Related: #404