True, I forgot about Graal. IIUC though that's somewhat different from what WebAssembly has done- Graal doesn't define any sort of stable compiler target for C, or produce JVM bytecode from C, but instead (via Truffle) JITs C source or LLVM IR via partial evaluation, right?

That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.

No that's right, the stable compiler target is someone else's job.

But I wasn't comparing to WebAssembly, so you'll need to argue that point with someone else.

You could build a WebAssembly interpreter on Truffle, yes. I'm not sure anyone's tried it yet so that project is available.

> You can run all those languages on top of the JVM!

Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.

For example Sulong runs C, C++, Rust https://llvm.org/devmtg/2016-01/slides/Sulong.pdf.

I use it to run unmodified C extensions for the Ruby programming language on top of the JVM.

Truffle C is another example https://www.manuelrigger.at/downloads/trufflec_thesis.pdf.

Thanks to GraalVM. Well, that wasn't always the case and it prompted the need for WASM.

Webassembly came from asm.js, which came from Emscripten. These 3 are a lineage of the same c compilation model targeting a JS Uint8Array as the c heap. Emscripten was published a long time ago, probably 10 years? So, JVM has byte arrays too...