This is about using native-image for the Graal compiler when used as a JIT in HotSpot. There are Windows builds for this available here[1]. Not sure what you mean by position independent code in the context of libgraal. But I don't think it is relevant.
The GraalVM compiler emits native code. It consumes JVM bytecode, or intermediate representations of other programming languages implemented using the Truffle framework.
I assume that a WASM backend could be created for Graal Native Image, so that it could compile Java byteocde to WASM ahead of time, but I wonder what benefits that would have over compiling bytecode to JS (as TeaVM does).
There is now a pure wasm version of TeaVM.
My idea was that graal could run in wasm and compile to wasm, the (only) benefits would be faster and smaller code.
I'm not sure it would be either. JS has a good JIT that Java code can significantly benefit from (much more than, say, C) -- WASM doesn't, so compiling to JS could actually be faster; JS also has a GC and WASM doesn't, which means that the image must contain a GC, making it larger, not smaller. Either way, it's speculation, but I don't think it's obvious that compiling Java bytecode to WASM is preferable to compiling it to JS, but maybe the TeaVM maintainers can share their experience.
