FYI: prototyping work in wabt and V8

[jakobkummerow]

Just FYI to anyone who's interested: we have started prototyping this proposal in both wabt and V8.
We've consolidated the plan for the prototypes in this document to ensure that both implementations are compatible.

I'd like to emphasize that we're not trying to shortcut or sidestep the ongoing discussion about the specifics of the proposal. The prototypes will not ship (they will remain behind off-by-default flags). We will ship whatever the outcome of the proposal/spec process will be. The prototypes do not constitute an expression of preference/opinion on any of the open questions.

Instead, the idea is to (1) start making progress with the core implementation work we will (most likely) have to do at some point anyway, and (2) hopefully be able to provide feedback to the ongoing discussion, e.g. around practical feasibility of structural type checking, although to be really meaningful this might require some Wasm producers (i.e., source languages) to volunteer to invest the effort to produce modules targeting the prototypes.

[lars-t-hansen]

That's great news. Firefox has also had a prototype for about a year or so, documented here.

[rossberg]

Excellent news! I'll push forward with the reference interpreter, probably focussing on the function refs and type imports proposals first.

[Horcrux7]

@lars-t-hansen Do you plan to adapt the binary coding of Firefox GC as soon as the implementation in WABT progresses?

I ask because I use your code for my tests.

[skuzmich]

Kotlin/Wasm prototype also currently targets Firefox GC instruction set. In order to fully port it to WABT and V8 we would need optref, ref.cast and ref.test on top of the MVA.

[RossTate]

Cool! Regarding (2), it will be helpful if you make it easy to turn on and off optimizations, since some optimizations we can rely on now we might not be able to rely on in the future, so it'd be nice to know how critical that reliance is.

And yes, we need to get some languages to work on targeting this extension. Great to hear that Kotlin is already working on it! I think OCaml is working on it too. I'll see if I can rally some more, ideally from the dynamic languages.

[binji]

@skuzmich thanks for the info! I'll make sure to work on those next.

[lars-t-hansen]

@lars-t-hansen Do you plan to adapt the binary coding of Firefox GC as soon as the implementation in WABT progresses?

In general, the Firefox implementation can be changed to be compatible with whatever, as few people are using it. I've not looked at what @binji's done yet, but if it's incompatible with what I have then I guess we have to make the designs converge.

[binji]

I took a quick look, it seems like the main differences are these:

name	v8/wabt	FF
structtype form	0x5f	0x50
ref.eq	0xd3	0xf0
struct.new	0xfb00	0xfc50
struct.get	0xfb03	0xfc51
struct.set	0xfb06	0xfc52
struct.narrow	X	0xfc53

[skuzmich]

Another major difference is that FF (ref T) is v8 (optref T)

[lars-t-hansen]

FF also requires the presence of a special section in the module to enable the feature at all, https://github.com/lars-t-hansen/moz-gc-experiments/blob/master/version2.md#special-section-required. This was just paranoia on my part. If we're converging on some basic aspects of the design and some shared opcodes I could remove that requirement.

[lars-t-hansen]

Another major difference is that FF (ref T) is v8 (optref T)

That's just syntax, right? Easy enough to fix...

[binji]

I think optref is nullable and ref is non-nullable.
edit: ah, sorry I see what you mean. :-)

[Horcrux7]

@jakobkummerow It there any build of V8 that include this prototype for testing?

[jakobkummerow]

@Horcrux7 Not yet. The V8-side work is far from complete (even the "MVA" subset). I'll post an update here when there's something to play with.

[Horcrux7]

@jakobkummerow I think the MVA subset should be enough for first test.