Comment by WJW
2 days ago
I wonder if there's ever a point at which you could run a thread at very low "niceness" that just slowly keeps compiling more and more methods into native code as the program goes on. Surely this would be worth it for long lived server programs. You could even keep it around to periodically recompile methods if runtime information shows that some paths are hotter than others.
One reason is that the JIT needs info on the types passed to the method, which are only available after a few calls. Per the article, a+b could refer to any type of a and b. The only way to know what was used is profiling.
The article targets MRI (Matzes Ruby Interpreter). It does not execute threads concurrently. Probably for the same reason that Python imposes limits on threads - to stay single threaded when calling into C libraries, most of which were written before threads were important enough to think about them
While that's true for the running program, it doesn't stop the JIT engine running a thread to compile code as the parent comment suggested. It's not running the ruby code.
Quite common across Java (including its Android cousin) and .NET implementations.
This technique is used by some existing VMs. .NET does this with a background thread and calls it 'tiered compilation', where methods are queued for recompilation at a higher (more expensive/thorough) optimization level in the background. It's pretty helpful.
I believe most browser JS runtimes do it too.