Hacker News Reader

Comment by WJW | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com