Update Node status for GC

[samestep]

Using Binaryen v116, assemble pairs.wat

(module
  (type $pair (struct (field $fst f64) (field $snd f64)))
  (func (export "cons") (param $a f64) (param $b f64) (result (ref $pair))
    (struct.new $pair
      (local.get $a)
      (local.get $b)))
  (func (export "sub") (param $ab (ref $pair)) (result f64)
    (f64.sub
      (struct.get $pair $fst
        (local.get $ab))
      (struct.get $pair $snd
        (local.get $ab)))))

via this command:

wasm-as --enable-reference-types --enable-gc pairs.wat

Then download the Node nightlies from Jan 4 and Jan 5:

• https://nodejs.org/download/nightly/v22.0.0-nightly20240104084d761dfc/
• https://nodejs.org/download/nightly/v22.0.0-nightly2024010568c8472ed9/

And with each of those nightlies, try to run pairs.js

import * as fs from "fs/promises";

const bytes = await fs.readFile("pairs.wasm");
const mod = await WebAssembly.compile(bytes);
const { cons, sub } = (await WebAssembly.instantiate(mod)).exports;
const pair = cons(5, 3);
console.log(sub(pair));

via this command:

node --experimental-wasm-gc pairs.js

The Jan 5 nightly prints 2 to the console as expected, while the Jan 4 nightly instead gives this error message:

node:internal/process/esm_loader:34
      internalBinding('errors').triggerUncaughtException(
                                ^

[CompileError: WebAssembly.compile(): invalid value type 'stringref', enable with --experimental-wasm-stringref @+22]

Node.js v22.0.0-nightly20240104084d761dfc

[dschuff]

So this does match a V8 update to v11.9 in node (which matches Chrome 119 where this feature turned on by default), but it seems odd that the error you're getting is related to stringref rather than GC, because it's not obvious to me where a stringref would be coming from here. Maybe @tlively has a clue?
Also since the update is to 11.9, if node follows chrome, I might actually expect this to be the revision where you could use wasmGC without a flag. So maybe something else is going on here. @jakobkummerow did the flag flip by default happen in V8 or was it on the Chrome side?

[samestep]

From conversation with @titzer, it seems like the reason the error mentions stringref is that the opcodes were changed, so the new opcode for something in this struct example is the same as the old opcode for stringref. With regard to the flag: it is also true that the --experimental-wasm-gc is unnecessary for this example (if you use a Node nightly version from Jan 5 or later, node pairs.js works just fine). Because of that, should I modify this note to say as much? As I've currently written it, it seems to imply that --experimental-wasm-gc is necessary even after the Jan 5 nightly.

[dschuff]

Aha yes I forgot about that, that explains it. Yeah because of the opcode change we maybe shouldn't say that versions older than the nightly even have GC support, since the tools are now all emitting the new opcodes by default, and those binaries won't work at all on the older versions (even with the flag).
We could just say that node has full support starting in version 22, with no notes or anything. Currently you can only get 22 from nightlies, but once it graduates to "Current" we won't have to change the page. And from this point on, it's unlikely anyone will be using nightlies from before Jan 5. WDYT?

[samestep]

@dschuff Sounds good, done!

[jakobkummerow]

Just to confirm what you've already figured out:

• V8 v11.9.80 was the first tag that switched from the prototype binary encoding to the final binary encoding. For V8 versions before that, passing the --experimental-wasm-gc flag is rather pointless nowadays; it was useful only for Wasm modules that were produced with toolchains that emitted the prototype binary encoding.
• V8 v11.9.84 (later on the same day) was the first tag that enabled WasmGC by default. For V8 versions after that, passing the --experimental-wasm-gc flag is entirely unnecessary.
• The specific error message you get when trying to decode a modern (final encoding) Wasm module to an old (prototype encoding) V8 depends on what exactly that module contains; it is indeed possible to get a stringref-related message.

So, in summary, I think it's fair to say that Node 22 supports WasmGC without flags, and for any earlier Node version WasmGC is effectively impossible to use (even with flags, due to the binary encoding difference).

[dschuff]

Thanks, to both of you!