Repository navigation
FYI: prototyping work in wabt and V8 #81
Description
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.
Activity
lars-t-hansen commentedon Mar 18, 2020
That's great news. Firefox has also had a prototype for about a year or so, documented here.
rossberg commentedon Mar 18, 2020
Excellent news! I'll push forward with the reference interpreter, probably focussing on the function refs and type imports proposals first.
Horcrux7 commentedon Mar 18, 2020
@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 commentedon Mar 18, 2020
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.castandref.teston top of the MVA.RossTate commentedon Mar 18, 2020
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 commentedon Mar 18, 2020
@skuzmich thanks for the info! I'll make sure to work on those next.
lars-t-hansen commentedon Mar 19, 2020
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 commentedon Mar 19, 2020
I took a quick look, it seems like the main differences are these:
skuzmich commentedon Mar 19, 2020
Another major difference is that FF
(ref T)is v8(optref T)lars-t-hansen commentedon Mar 20, 2020
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 commentedon Mar 20, 2020
That's just syntax, right? Easy enough to fix...
binji commentedon Mar 20, 2020
I think
optrefis nullable andrefis non-nullable.edit: ah, sorry I see what you mean. :-)
Horcrux7 commentedon Mar 21, 2020
@jakobkummerow It there any build of V8 that include this prototype for testing?
jakobkummerow commentedon Mar 21, 2020
@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 commentedon Mar 22, 2020
@jakobkummerow I think the MVA subset should be enough for first test.
15 remaining items
rossberg commentedon Jun 29, 2020
Just to be clear, there currently is no plan for dropping i31ref. The GC proposal clearly needs a way to express unboxed scalars, and in a way that is predictable and works across platforms.
One could argue that this is just a performance improvement, and technically that's true. However, it also is such a fundamental feature that it should be part of the basic design evaluation that we want to do with the MVP. Without a proven way to incorporate unboxed scalars, practical usability of the GC extension will remain completely unclear for a whole range of languages.
jakobkummerow commentedon Jun 29, 2020
We will add i31ref to the V8 prototype soon.
aardappel commentedon Jun 29, 2020
@jakobkummerow would love to hear along what paths adding
i31refcauses conditionals.@rossberg that still appears to be a matter of opinion.
sabine commentedon Jul 17, 2020
Side question: to use the V8 prototype, we use the instructions at https://v8.dev/docs/build to build V8 from source, or is there a simpler/quicker method to get a build of the bleeding-edge V8?
skuzmich commentedon Jul 17, 2020
https://github.com/GoogleChromeLabs/jsvu is a handy tool that downloads and updates canary builds of V8 and other engines.
Horcrux7 commentedon Jul 17, 2020
@sabine I use https://github.com/nodejs/node-v8
It is a node build with v8-canary. You can download directly the binaries. But currently it is broken for Windows. Only the other platforms are available.
Horcrux7 commentedon Sep 17, 2020
@jakobkummerow Are you interested in bug reports or is it too early for that? Currently I have a crash with 0xC0000005.
binji commentedon Sep 17, 2020
FYI: I haven't made much progress on wabt, but I have implemented milestone2 support in wasp: https://github.com/binji/wasp
The plan is to merge the wasp library into wabt, but for now wasp has its own tool to do the text -> binary conversion.
jakobkummerow commentedon Sep 18, 2020
@Horcrux7 yes, I'm interested in bug reports. Probably makes sense not to derail this thread; you can email me (address in the doc linked in the OP) or file a bug at crbug.com/v8/new and assign it to me. Please include repro instructions :-)
jakobkummerow commentedon Jan 15, 2021
Heads up: we're planning to adopt the lastest changes to the proposal, which will break backwards compatibility. Please comment on this draft doc: https://docs.google.com/document/d/1yAWU3dbs8kUa_wcnnirDxUu9nEBsNfq0Xo90OWx6yuo/edit# if you have questions/comments/concerns.
[spec] Update instruction index (#81)
jakobkummerow commentedon May 27, 2021
FYI, we are currently adding support for two experimental instructions that are not (yet?) included in this proposal:
array.copy: copy a range of elements from one array to another, similar to bulk memory operationsrtt.fresh_sub: likertt.sub, but always creating a fresh RTT (never caching or canonicalizing), making it possible to express Java's type system in terms of RTT-based operations.Both instructions are described in our existing document: https://bit.ly/3cWcm6Q. To use them, pass the new flag
--experimental-wasm-gc-experimentstod8. The existing--experimental-wasm-gcflag will continue to enable only the features that are part of this proposal.The idea is to gather data, and in particular to verify the assumption that these instructions provide practical benefits. Depending on the results, we will either officially request that they (or something like them) be included in the GC proposal, or drop them again.
tlively commentedon Jun 16, 2022
Closing this issue since it hasn't been used for announcements in over a year, although note that we have continued to keep the link @jakobkummerow shared pointing to the latest version of the informal prototype spec as it has evolved.
jakobkummerow commentedon Jun 27, 2022
Here's an announcement :-) (but I'm happy to keep this issue closed)
For a while now, "milestone 5" of the prototype spec has been the de-facto state of things despite officially still being marked as "draft". I've just made it official to reflect reality. It's at the old link: https://bit.ly/3cWcm6Q
A number of backwards-incompatible changes have accumulated recently; we're planning to incorporate those in the next version of the prototype spec, so that'll be a breaking change. Details TBD -- I guess we'll prepare patches (and/or land code behind flags), make some announcement, and then flip the switch (in a coordinated manner across both V8 and Binaryen).