I assume the GP was referring to wasm running on top of graal, not graal running on top of wasm.
I don't think graal atop wasm would be a particularly interesting use case. Wasm purports to be a portable, secure, performant application runtime. Graal purports to be a portable, secure , performant application runtime. The latter, however, has had many more engineer-hours thrown at its implementation, and is thus both more heavyweight (so it needs all the resources it can get) and more performant (so it makes sense to use it as the backing runtime).
Wasm is build as an efficient target for C/C++ like languages. It's mostly a striped down portable CPU intruction set. Graal/Truffle is intended to be an efficient target for everything. It's a toolbox of crazy magic for building your own JIT.
There are not equivalent.
What if somebody will build a GraalVM-based browser? That would be something. Anyway, W3C recommends WebAssembly but does not impose it. It is not too late in the game because WASM doesn't even have DOM access, yet. And also people are still using browsers that are not WASM-ready. How many people actually compile their libraries to WASM today? Aside to early adopters scattered around Rust and Emscripten.
I don't see which actor in the industry (outside of browser makers) has the human resources to make such an experiment.
Mozilla were the one lobbying for wasm... and chromium has abandoned pnacl because of them. The only hope might be microsoft.
Oracle could do it in theory but I don't expect them to do it anytime soon.
GraalVM can output LLVM, which can go to WASM. In the past it also used to be able to output JavaScript. It should be easy enough to make it output WASM directly.
The GC is written in Java, so if you have the translation to WASM that's covered as well.
