from Hacker News

Running JRuby on the Graal JIT

by headius on 7/3/18, 10:01 PM with 36 comments

• by Lio on 7/4/18, 6:52 AM

  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

• by pella on 7/4/18, 1:17 AM

  "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"

  - ...

• by kovrik on 7/4/18, 12:19 AM

  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.

• by nobleach on 7/4/18, 1:07 AM

  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!

• by phd514 on 7/4/18, 2:49 PM

  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.

• by mark_l_watson on 7/3/18, 11:56 PM

  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?

• by nurettin on 7/4/18, 4:22 AM

  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.

• by dr_faustus on 7/4/18, 8:38 PM

  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.

• by Confusion on 7/4/18, 2:49 PM

  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.