Comment by manwe150
2 days ago
I don’t think that answers GPs question. They asked it could be fast (a result), not if it could use a JIT (an implementation detail). I would argue it is an easy language to JIT since its semantics are clear and straightforward, just that it might not gain any speed if there aren’t any optimizations it can apply over the code run in the JIT.
If you want an example of a bad language to JIT, take C for example, where parsing and running code is hugely context dependent and adding new code can change just about anything about the existing code without anything knowing about it. And yet most C runs via a JIT: dlopen, the just in time loader. Just look at the mess that is historic ELF to attempt to deal with the problem
They asked if it could be "as fast as the JVM", which JIT is a crucial part of how the JVM achieves its performance. JIT in this context is referring to the process of a source file (.rb, .js, .c, etc), or usually bytecode, being compiled into machine code. I cannot think of an instance where a C source file is JIT compiled and dlopen(3) will not be happy if you tried to call it on a C source file.
And yet we were just talking about the JVM, which will not be happy if you tried to call it on a Java source file. Or is WASM an AOT compiler because it runs the equivalent dlopen of C code somewhat slower than the native dlopen?
Bytecode is not machine code, and I specifically said source files "or usually bytecode". A C program is compiled into machine code (and more specifically a platforms given executable format) before dlopen(3) is called on it. Not sure what point you're really trying to make.
1 reply →