WebAssembly is lower level with raw memory management, meant primary for running low-level languages in the browser.
Graal instead is a bit more complex to describe, since it incorporates many things. Perhaps the most important part of it is an abstract syntax tree-based interpreter, which can be used to implement a dynamic language with ease, and Graal can basically convert such an interpreter to a language runtime that uses the many many advancements behind the JVM like advanced JIT, GCs and the like. Such an implementation for small languages can easily surpass the “host” runtime in performance, for example R, Ruby.
What makes graal even more interesting is that this intermediate AST is language agnostic, it basically maps the guest language to JVM built-ins — this allows completely polyglot code bases (with JIT compilation between boundaries) and even has an llvm ir-based interpreter because dynamic languages often have C-based standard libs (and since it can inline between deps now, it may be faster than native FFI). But the whitepaper titled One VM to rule them all could give a much better overview than I could.
Since it is primarily a JIT compiler, it can be used as AOT as well.
The simplest way to think of Graalvm is that it’s not a VM, it’s just a plungin replacement for Hotspot.
Hotspot is written in C++ and hard to change. So once the java JIT is written in java it will be easier to innovate.
But then they took the base and used the java to machine code capabilities to be able to do ahead of time compilation to machine code.
But the most amazing part is that if you use the graal apis to define an interpreter for a language (any language) then graal can generate a compiler from that interpreter. It will compile all that is known at compile time and leave to runtime what needs to happen at runtime. So essentially it does partial compilation.
Yup, they are very similar as both are used to run code at high performance.
WebAssembly was designed for the browser. Users want their websites to load quickly, so startup time is crucial. Also, users want to browse sketchy websites, so security is also crucial. WebAssembly is more like an instruction set for a "fake" CPU. It's very low-level and is not ideal for running high-level languages like Ruby (though it's possible!).
On the other hand, GraalVM isn't constrained by these browser requirements. This lets Graal do nifty tricks so that highly dynamic languages - like Ruby or JavaScript - run as fast as possible.
