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.
Slightly longer answer: no, because Ruby as a language isn't designed to be JIT friendly. Any web request in my rails app could theoretically add new functions to any other class, in ways that would just not work in most other languages. This wreaks havoc on JIT compilers, because they constantly need to check if the assumptions they made when compiling certain bits of code still hold or if the entire world has shifted out from underneath them. This is a super beloved aspect of Ruby, but is just not JIT friendly.
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.
I wonder if Ruby's VM will ever become as fast as the JVM
Short answer: no.
Slightly longer answer: no, because Ruby as a language isn't designed to be JIT friendly. Any web request in my rails app could theoretically add new functions to any other class, in ways that would just not work in most other languages. This wreaks havoc on JIT compilers, because they constantly need to check if the assumptions they made when compiling certain bits of code still hold or if the entire world has shifted out from underneath them. This is a super beloved aspect of Ruby, but is just not JIT friendly.
Even V8 isn't as fast as JVM :) I think only LuaJIT is comparable in some ways.