Chris Seaton

While probably less common in Java, the language supports dynamic class loading, reflection, runtime bytecode generation, invokedynamic, and other features that can break static assumptions. The JVM does need to deal with all of this and does so with speculative optimization and deoptimization.

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…

JIT has little to do with interoperation. It's quite simple to generate C symbols pointing to stubs. What makes interoperation hard is usually a GC rather than a JIT (it's just that most JITted languages also employ a GC; but if you look at, say, Go, it's just as hard to embed or link against than as and it doesn't employ a JIT at all -- its runtime "just" performs scheduling and GC).

---

BTW, Java can be embedded in scripting languages because those languages run on the platform itself and share the runtime. Because of the JIT -- that optimizes across libraries and languages -- the interoperation is cheaper than with C. So much so, that you get the following story: As part of the work being done at Oracle on Graal, HotSpot's next-gen JIT, they've ported various scripting languages to the new JIT, among them Ruby. They've found[1] that if they interpret/JIT the C code of the native Ruby extensions they get better performance than a "plain" Ruby runtime calling into statically compiled C, because the JIT is able to optimize across the language barrier.

[1]: http://www.chrisseaton.com/rubytruffle/cext/

>wants to fight about politics or other wedge issues

It's always so funny that this is brought up on HN as a reason for lack of socialization or problem so often. One of the biggest and most durable parts of my social life is being a member of a political party, which I have been in since I was 16 years old.

Being involved in civic/political life means you have connections with people from all walks of life across all generations and backgrounds. just wanting to chill is the actual problem because I don't think these suburban soccermom type social circles sustain meaningful relationships. Participating in public life is the most straightforward way to build social relationships that matter.

There was another great post here a few weeks ago from someone explaining why he continues to serve in the British Yeomanry. https://chrisseaton.com/army/

source: https://chrisseaton.com/truffleruby/

> TruffleRuby started as my internship project at Oracle Labs in early 2013. It is an implementation of the Ruby programming language on the JVM, using the Graal dynamic compiler and the Truffle AST interpreter framework. TruffleRuby can achieve peak performance well beyond that possible in JRuby at the same time as being a significantly simpler system. In early 2014 it was open sourced and integrated into JRuby for incubation, then in 2017 it became its own project, and now it is part of GraalVM. Since 2019 Shopify has sponsored development.

> In early 2014 it was open sourced and integrated into JRuby for incubation

Additionally, we also tried Truffle when it was JRuby, or in JRuby, however you want to put it, but without a lot of success. Things could be different now.

You can do fake pointer arithmetic which won't hurt this use case (server-side web framework); if you implement Gforth as an interpreter on the JVM/CLR or running it with Emscripten, there is no issue for server-side web frameworks like this while being safe.

That's been done for C a few times (this [0] and there are a few others); if you don't depend on the actual physical memory addresses you are using (which, in embedded, you often are counting on, but not in a server-side framework).

> it's more a a cultural thing than a technical thing.

I agree with that

> IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.

Not sure what this means?

[0] https://chrisseaton.com/plas15/safec.pdf

I don't know Ruby, so I had never paid JRuby any attention or heard of any of this, despite writing VMs for fun and following PyPy development. This talk was amazing. The fact that you include a C parser and interpreter (CTruffle) [1], can parse (some) MRI Ruby extensions written in C, and treat it just same as Ruby and inline/partially evaluate/etc everything together, and hence run faster than compiled C extensions, is just mind blowing. And it's all JIT compiled to JVM bytecode which then gets JIT compiled by HotSpot, what an incredibly complex stack.

[1] http://chrisseaton.com/rubytruffle/cext/

It makes me wonder about writing a JIT compiler to produce LuaJIT bytecode, since I'm currently working on AOT compilation of a dynamic language to LuaJIT bytecode.