proposals
proposals copied to clipboard
WebAssembly
How to track implementation status?
Reading over the proposals the phase tags are a great way to get a high-level idea about where a proposal is in the process, but one thing I've found that's somewhat difficult to figure out is the actual concrete implementation status. While the phases imply some degree of implementation, I've found it also nice to know the concrete status in various engines.
For example, SIMD is implemented Node, but it disagrees with LLVM's opcode definitions. Bulk memory operations have recently been implemented in Firefox, but are currently temporarily diverged from the spec in terms of encoding. Atomic instructions and SharedArrayBuffer seem to be implemented in a lot of places!
Would it be possible to have a section either on each proposal itself (in the proposal repository) or in this tracking repository (via the issues or the README) to have a location to edit about the current status? This may also be a bit of a pipe dream because these sorts of statuses are notoriously hard to keep up to date.
This is largely motivated from a desire to test out reference types especially because it's in phase 3 which seems much farther along than many other proposals! At the outset though I don't actually know where I could test it (Firefox? Node? Chome? Safari?) and I'll be digging into various engines to see implementation statuses. For example I know Firefox doesn't support anyref tables right now, but that was learned through other means!
Do others feel like it's possible to do this? I'd also be fine ruling this under "there's so few people this'd apply to it's not worth the effort", as that seems totally reasonable to me!
I think this would be useful if it were accurate, but I think it may be too hard to maintain as documentation, especially if you want specific information as you mentioned above. That said, I can imagine someone making something like https://wpt.fyi or https://kangax.github.io/compat-table/es6/ using tests from proposals (or writing their own), though that would be a lot of work to maintain too.
Not saying we should give up, though! Maybe it's enough to ask champions occasionally to give updates on implementation status, and try to provide high-level updates on the proposal repos. In addition, if other folks want to dig in and track the info down, I'd encourage submitting PRs with that info.
Perhaps something like:
| Engine/Tool | Status |
|---|---|
| v8 | implementation behind flag --experimental-frob |
| wabt | implemented, no interpreter support |
Something automated would be neat, but also hard to automatically capture the "behind --experimental-frob" state. What about just adding a new (wide) column that different wasm consumers could self-fill-in?
This could be even harder if we want to test not just browser engines but also other environments.
Ah @binji that sounds like a great idea! I think another way to phrase this is "I'd recently learned about the implementation state of a few proposals but didn't see it written down, and I was curious if there was a location I could write it down too". I think this could definitely be solved with a contributor-driven section which perhaps has some qualifying text above it about how it may be out of date.
I'd also imagine that this could be relatively free-form in the sense that it wouldn't want to be too strict about format (like @lukewagner I can't imagine this being automatically populated).
Probably we can use eshost to test JS engines and collect some data. I'll try to build a prototype when I'll have some free time.
Nice project by Bocoup: https://test262.report. Unfortunately it doesn't cover WebAssembly built-in Object.
The following table shows the status of future WebAssembly features required by JWebAssembly in nightly builds in various implementations according to my tests.
| Feature | V8 | SpiderMonkey | WABT |
|---|---|---|---|
| floar-to-int | yes | yes | yes |
| Sign-extension | yes | yes | yes |
| Multi-value | yes | - | yes |
| Reference Types | yes | yes | - |
| Garbage collection | - | partly | - |
| Exceptions | partly | - | partly |
- For V8 it based on the V8 - node.js integrations builds.
- For SpiderMonkey it based on the nightly build of jsshell.
- For WABT it based on libwabt.js via node module wabt@nightly.
To use it also some flags and switches are needed.
Has anyone brought up support for fat modules with thunks that are rewritten to the supported version once the feature is detected or not? This would be similar to game engines detecting GPU or SSE extensions once on boot and then hard coding the jump there after. The spec itself would have to support the jump table rewrite on feature detect since general code writing is disallowed for security.
@KronicDeth if I understand you correctly, "jump" is possible already via call_indirect. WebAssembly still lacks feature detection though. I think that something like ( has_feature "simd" ) along with i32.eq / i32.eqz and call_indirect might work.
Since feature detection (for most features anyway) is currently only possible from the host environment (via validation and selective module instantiation) and one thereafter has to do an intermodule indirect call to the dynamically selected module to use the feature or the polyfill, dynamically selected features have a bit of overhead both for setup and use.
But there's been pretty broad agreement so far that there is no "simd" feature in wasm; implementations are in principle free to support subsets of a proposal and of course post-mvp some implementations may support the mvp and some may support more than that. Additionally, there will be bugs to work around, so there may be a time when polyfilling one operation of a proposal will be attractive. IMO we'd be better off making sure indirect calls are very fast (once we have proper function types this will get a little better) and perhaps finding ways to express the module selection logic into wasm to decouple it from the host, when possible.
We've discussed a number of times providing some kind of "validation failure boundary", where functions can optionally fail validation, and if they do, will be replaced by unreachable. Then an instruction can be added to query whether that validation succeeded. That said, even this functionality wouldn't work w/ things like SIMD, which requires changes to the type section too. But I think there's potentially a nice solution here -- we just need more design work.