
Running JRuby on the Graal JIT - headius
http://blog.headius.com/2018/07/running-jruby-on-graal-jit.html
======
Lio
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](https://github.com/ruby-concurrency/concurrent-ruby)

~~~
headius
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.

~~~
Lio
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.

~~~
headius
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!

------
pella
"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...](https://www.ruby-
lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/)

\--

Some benchmarks ( 2017! )

[https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-...](https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-
organization)

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

\- ...

~~~
chrisseaton
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](https://youtu.be/emhYoI_RiOA?t=7m41s)

~~~
pella
thanks for the youtube-video link!

------
kovrik
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.

~~~
bad_user
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](https://eta-lang.org)

~~~
kovrik
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.

------
nobleach
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!

~~~
qop
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!

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

But, still very cool yeah!

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

------
phd514
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.

~~~
headius
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.

------
mark_l_watson
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?

~~~
headius
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.

~~~
kjeetgill
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?

~~~
headius
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.

------
nurettin
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.

~~~
headius
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.

~~~
nurettin
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.

------
dr_faustus
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.

~~~
headius
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.

~~~
dr_faustus
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!

------
Confusion
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.

~~~
headius
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.

~~~
Confusion
Awesome, thanks for your response!

