▲ | 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 | ||||||||||||||||||||||||||
▲ | jntun 2 days ago | parent [-] | |||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||
|