TruffleRuby applies many of these same techniques to Ruby to great effect. Fortunately, most applications stabilize at some point and a JIT compiler can do wonders. E.g., TruffleRuby has had zero-overhead metaprogramming for a decade now[1]. But, these optimizations incur trade-offs. TruffleRuby has a Ruby core library mostly written in Ruby to help optimization, but that means the interpreter takes a performance hit. The CRuby VM has most of its core library written in C because the team favors having a fast interpreter with low overhead, which is great, but means much of the core library can't be JIT compiled alongside an application.

I think the real answer why the CRuby VM lags behind the JVM is more pedestrian: there's been orders of magnitude more investment made into the JVM than any Ruby VM. Sun and then Oracle have hired world class VM developers and researchers to work on multiple JIT compilers, multiple GC implementations, fast tooling, a standard memory model, world-class concurrency library, and so on. OpenJDK sees heavy investment by many others, too (RedHat probably leading the charge). And then you have other vendors advancing the state of the art with alternative VM implementations (Azul, IBM, Amazon, etc.).

Ruby as a language has seen loads of research done on compilation and alternative VMs [2], but the CRuby VM itself hasn't seen anything close to OpenJDK's investment. That's not to say there isn't excellent work being done to improve the CRuby VM. But, production VMs are large, complex projects and not the sort of thing easily moved by a volunteer working nights and weekends. More investment by companies using Ruby would help close the gap.

[1] -- https://chrisseaton.com/rubytruffle/pldi15-metaprogramming/p... (FYI, the paper refers to JRuby+Truffle, which is TruffleRuby's old name).

[2] -- https://ruby-compilers.com/

JRuby is a thing and it runs on the JVM as more than a simple interpreter. The JVM does have to deal with this exact problem. So you could actually say Ruby can already run as fast as the JVM because it runs on it, what it cannot do is run as fast as a static language because, at the very least, it has to deal with additional checks that things haven't changed.

Java Spring applications pretty much do the same thing (reflections, proxy beans, aop, JSON/Date serializers/deserializers, ORMs, etc are all compiled and changed dynamically upon route hits).

These things are theoretically possible (and happen) in any JIT language (node, java). Only statically compiled languages seems to be immune to this.

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