Running JRuby on the Graal JIT | Hacker News Reader

Running JRuby on the Graal JIT

blog.headius.com

173 pointsheadius36 comments

I’m working on a project right now that uses jruby for java interaction.

I’m so appreciative that we have an easy way to combine java code with ruby scripting, thanks Charles. You guys make my job possible. :D

I think particularly now that we have the excellent concurrent-ruby[0] project more developers should checkout jruby.

My suspicion is that the main pain point stopping people using jruby is around tooling and process forking.

The ruby tools I would normally use to get fast cycle times for things like running specs without restarting rails mostly rely seem to make use of forking which obviously isn't supported on the JVM.

If I can find more time and tallent that’s definitely something I look into.

[0] https://github.com/ruby-concurrency/concurrent-ruby

Yes the development experience is unfortunately a problem for all the optimizing Ruby runtimes. TruffleRuby with its SubstrateVM precompiling improves this situation quite a bit for trivial commands, but still takes longer than CRuby to boot any large application (e.g. Rails). I have plans to try to improve startup in JRuby using some new AOT compilation and code caching features of Java 10.

That will be brilliant Charles. Too be honest I think if we can keep the main JVM process up and running but get code reloaded that would probably smooth things a lot.

I sort of hope that we, the rest of the community, could take care of that for you. Although faster start up would be awesome in general.

I believe much of the work on forking preloaders could be modified to work with a single JRuby JVM process, or with the Drip JVM preloader. Hopefully we'll have time to make that happen, or someone from the community will step up to help us!

"Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler."

https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-prev...

Some benchmarks ( 2017! )

https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-...

- "Graal is too aggressive with compilations and almost always needs more CPU work than MRI interpreter"

- "JRuby and Graal are the worst with memory consumption"

- ...

Of course it's going to initially take more CPU work to just-in-time compile something than to just interpret it.

Of course it's going to initially take more memory to just-in-time compile something than to just interpret it.

Most just-in-time compilers will also include an interpreter, so yes you get the same time and space needed to run to run the interpreter, and then you get extra time and space needed to run the compiler as well.

I don't really see why this would surprise anyone!

You just hope that over time it pays off when you get the faster code out of the end of it, which isn't something Makarov gave them a chance to do in this post. You'll notice that when he moves beyond running micro-benchmarks, and starts to run things like OptCarrot in later posts than this and with more reasonable time for warmup, he then sees the pay off of the more sophisticated just-in-time compilers.

> still the results are worse than the latest Graal Ruby

https://youtu.be/emhYoI_RiOA?t=7m41s

thanks for the youtube-video link!

Chris covered this pretty well, but you'll notice in my post and in the slides from my RubyC talk (https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018) I usually include CRuby + JIT from this year in the results. It rarely helps more than a few percentage points, even on numeric algorithms, so I'd say it's too early to claim anything about it.

Great stuff!

Devs often complain about Java being boring and old-school, but it never ceases to amaze me how cool Java and Java-related techs are (JDK, JVM, GC etc.)!

Literally, state of the art, almost alien technology. And it seems that more cool stuff is coming.

There's always more cool stuff! I'm hoping to leverage more and more of the work being done for Graal and Truffle in standard JRuby over the next year. Keep an eye out for Graal-specific improvements in JRuby releases soon.

There are also alternative languages flourishing on top of the JVM.

Besides JRuby mentioned in TFA, there are awesome languages you can use like Scala, Clojure, Kotlin or even Haskell [0], all enabled by a runtime that proved to be truly multi-language, as in alternative languages are not just superficial syntactic sugar for Java (like CoffeeScript is for JS, or VB.NET is for C#).

Every time I have to use Java, the language, I hate it, however those languages are not Java, yet can leverage the decades of knowledge, libraries and tools built on top of the JVM.

It's a little funny in retrospective, I remember Microsoft's marketing in early 2000 and .NET developers were saying "Java is single language, multi-platform and .NET is multi-language, single-platform". Nowadays both statements are false.

[0] https://eta-lang.org

True! Personally, I'm in love with Kotlin. But also like Clojure. However, it is really nice to see that Java itself is getting better and better each release.

Err, the partially flow sensitive escape analysis talked about here is a generally decades old technique. The only interesting part is making it practical for JITs by being able to choose which branches to care about.

And honestly, while well thought out and engineered, it hardly qualifies as almost alien technology.

The thesis it's based on points out there are no published papers covering exactly this technique, but are in fact two other production implementations that do basically the same thing (luajit and pypy) that exist.

That's usually a really good sign that what you've done is not that novel (in the sense of being straightforward to those in the world) even if it is really good engineering.

Back in 2013, when I worked for the Federal Gov, JRuby was the best way to get Ruby on Rails apps to run in a Windows-only world. I absolutely love the work that folks like Charles do!

Feds used Rails? That's neat!

If you don't mine telling, were you a contractor or like a permanent dev? I'm very surprised that feds would choose Rails for projects. Maybe for prototypes or in house stuff or whatever.

Anyways, cool!

Federal Government does not necessarily equal cool FBI agents with suits and trenchcoats.

But, still very cool yeah!

Well, I'd expect more people associate federal jobs with the movie Office Space or the "hustle" of their local DMV.

Ha, yeah, FAR from "cool". But we did deal with some cool satellite imagery, and I can confirm, the earth is indeed roundish.

Can’t say for the US government, but a lot of GOV.UK (including all of the content pages, and some of the services) are built using RoR.

I was a contractor for the Forest Service at the Remote Sensing Application Center in Utah. The Rails tools were mostly internal... but yup, I lobbied hard to be allowed to write something other than PHP, C#, or Java.

Great to hear it! JRuby has always tried to be the best "JVM Ruby" it can be, which means we've spent more time getting things like Rails to run inside a normal JVM or application server than anyone else. I don't see that changing going forward...if you want to run a standard JVM, JRuby's the only game in town.

There's some impressive engineering involved in JRuby and some interesting possibilities with the Graal JIT. That said, I've had a net negative experience working on a product with a mix of Java and JRuby code. The JRuby LOC was in the high 5 to low 6-digit figures and while the interop with Java was good (so long as it was done carefully in performance-critical sections), the instability of the JRuby 9k releases was so bad that we spent an inordinate amount of time tracking down regressions. We also had a kind of chicken and egg problem keeping current with newer Java versions because that required newer JRuby releases but those introduced more regressions. Unfortunately, the net effect of all of this is that the product is languishing because of the development effort required just to keep it current let alone to develop new features. At least in our case, choosing JRuby as a platform proved to be a strategic mistake.

I'm sorry to hear this! We have worked very hard to keep JRuby stable, but sometimes things drift when more issues come in than we can keep up with. If you can point me toward the issues you're having, I'll try to prioritize them for the next release.

It sounds like you are trying to update to newer JVMs but running into problems, yes? I did a bunch of work about six months ago to support Java 9+ JVMs better, but I know there's more to do; the module system it introduce is tricky to work with/around.

Thanks Charles, exciting stuff. Ruby and JRuby have mostly been fast enough for my applications, but faster is better. Will it be a year or two before a standard JRuby distribution contains the free version of Graal?

JRuby 9.2 already included some general improvements designed to help Graal optimize, and 9.2.x will continue that process. I have already landed logic in 9.2.1 that will "right-size" objects based on observed instance variables, and I'm hoping to land a 64-bit long/double version of Array that will reduce the cost of numeric algorithms that use arrays (e.g. matrices, image manipulation).

I don't know that we will really need to ever ship Graal; if you get OpenJDK 10+ you'll have it available. However we may at some point detect that Graal is available and turn it on for you. In the short term, the JAVA_OPTS env var is pretty simple to use, or just run on the community version of GraalVM that uses Graal JIT by default.

Hey Charles! Since we have you here, can you clarify the differentiation between JRuby and TruffleRuby? Do they fit different niches? Is TruffleRuby parallel work that may eventually merged into or succeeded TruffleRuby?

TruffleRuby and JRuby have always been separate projects, but TR kinda "grew up" as part of JRuby for a couple years. Eventually we decided the goals were becoming too different so TR split back off into its own project.

We still communicate, we share several support libraries, and I'm sure we'll mimic some of their optimizations just like they've mimicked some of our features, but there's not a lot of commonality between the projects anymore.

I wonder what happened to torquebox. Back in it's glorious days, it provided a STOMP messaging service, an infinispan session store and JBoss server for Rails applications running on JRuby.

Torquebox was indeed a great server, but never generated enough interest from the Ruby community to become a full product. Without that, sadly, the developers didn't have a lot of motivation to keep working on it.

My only problem with the server was the fact that classes that were generated at runtime couldn't be garbage collected, and that required a reboot of the server after some time.

I really admire the work of Charles et. al. and we have a couple of Rails apps on top of Jruby in production. Unfortunately, while the language implementation is itself is developed constantly, the ecosystem has stalled.

The activercord jdbc driver implementation is particularly problematic because it effectively keeps us from upgrading to Rails 5 (we use SQL Server as backend). There is also a lack of app server options. The Jruby app servers like Trinidad or Torquebox are not maintained. Warbler has issues, too.

Charles and the other devs can, of course, spend their time however they want, but from my perspective, having a well maintained software stack for production deployments is far more important than a further speed optimization.

I'm not sure if you've looked recently, but we support the big three databases up through Rails 5.0, with sqlite3 support available for 5.1 and mysql and pgsql coming very soon. We need help keeping up, but we're not that far behind anymore after making a big push for Rails compatibility this past year.

SQL Server support still exists in our codebase but it has not been updated due to lack of resources. We want to continue to support it, but there's only three of us working on this stuff at all, and only two do this as our jobs!

As far as app servers...we recommend deploying like other Ruby folks do, using Puma as a server in multithreaded mode. Torquebox has unfortunately been put on hold because there are no resources to maintain it...but Puma works very well.

Charles, thanks for the reply. You guys are doing a really great job and the fact that you are only three main devs is just amazing!

I wonder whether this means we should not expect any more performance improvements on a < Java 10 JVM. That would be good to know, as that influences what I can expect for code running at a place that just upgraded to Java 8 and probably won’t switch to 10+ for many years to come.

JRuby 9.2 will continue to support Java 8 through the end of the year, and then we'll reevaluate minimum Java version for JRuby 9.3 early in 2019. Maintaining support for older JVMs, especially ones that have been officially end-of-lifed, does put a strain on our efforts to keep JRuby current, but I understand the move from 8 to 9/10/11 is a tough pill to swallow.

That said...the work we're doing to perform better on Graal will also speed things up on non-Graal JVMs: inlining more code, specializing data structures, reducing call overhead. You can rest assured things will continue to improve on Java 8 as well.

Awesome, thanks for your response!

Reply on news.ycombinator.com