JRuby at 15 Years: Meeting the Challenges

Talks

Charles Nutter

#java-virtual-machine-jvm

JRuby at 15 Years: Meeting the Challenges

by Charles Nutter and Thomas E Enebo

The video titled JRuby at 15 Years: Meeting the Challenges, presented by Thomas E. Enebo and Charles Nutter at RubyKaigi 2017, addresses the evolution and future challenges of JRuby, the most widely used alternative Ruby implementation. The speakers discussed several key topics reflecting the growth and ongoing development of JRuby over the past 15 years, focusing particularly on performance, compatibility, and community engagement.

Key Points Discussed:

Current Status and Roadmap:
- JRuby 1.7 has reached the end of its life, and the JRuby 9.1 branch supports Ruby 2/3 features, with a new JRuby 9.2 expected to release soon, setting the minimum Java version to Java 8.
Startup Time:
- Startup time is the time taken before user code execution begins. The comparison highlights that JRuby has a slower startup and warm-up time compared to C Ruby but aims to improve peak performance through various optimizations.
- Current startup involves loading a significant number of Java classes, and discussions are ongoing to explore ahead-of-time (AOT) compilation to improve these metrics using technologies like Oracle's Substrate VM and the commercial product, Excelsior Jet.
Warm-Up Time:
- JRuby experiences slower warm-up times but is focusing on optimizing the method conversion process, aiming to enhance performance by implementing a new profiling mechanism to identify frequently called code segments.
Compatibility Challenges:
- Compatibility with C Ruby remains a challenge due to differences in Ruby specifications and various internal behaviors between JRuby and MRI. The team dedicates about 90% of their efforts to resolving compatibility issues, including addressing bugs reported by users and ensuring functional alignment with MRI features.
- Ongoing efforts include developing a façade API to ease the transition for developers porting their C extensions.
Community Engagement:
- With only two full-time developers, the JRuby team encourages community contributions across various aspects, from bug fixes to enhancements in documentation.

Significant Examples:

The inefficiencies observed in executing commands like 'gem list', which currently takes substantial time due to the compilation requirements in JRuby, illustrate the performance issues that the team is actively addressing.
The discussion about integration complexities with C extensions shows the technical challenges posed by differences in memory management across Ruby implementations.

Conclusions and Takeaways:

While JRuby shows promising performance improvements, ongoing optimizations are essential for both startup and warm-up times to remain competitive with C Ruby.
Maintaining compatibility with MRI and ensuring a robust community of contributors are vital for JRuby’s future success.
Feedback and collaboration from the Ruby community play an integral role in enhancing JRuby, underscoring the need for active engagement from developers.
This talk not only reflects on past achievements but also sets the stage for the challenges and direction of JRuby going forward.

00:00:08.880 As of last year, JRuby 1.7 has reached the end of its life. If you want 1.9 support, then you'll have to go elsewhere. We have a JRuby 9.1 branch that supports our Ruby 2/3 initiative, and we anticipate that this branch will last for probably the next year. On the master branch, we're working on JRuby 9.2, which we think is going to come out this year for sure.

00:00:36.030 This release will set the minimum version of Java to Java 8, and we've already started making the required changes. Now, the first section of our talk focuses on three kinds of time.

00:01:00.030 The first kind is startup time, which is how long it takes before you can start executing your user code. The simplest example of this is measuring how long it takes to evaluate your first line of code. The next kind of time is warm-up time. If you use an optimizing runtime like the JVM with JRuby, you might find that your code isn't very fast right away, but after some time, it will reach its peak performance.

00:01:51.060 If you run a server or a long process, peak performance is crucial. If you're running a command-line utility, startup performance matters more. In many cases, we only care about warm-up performance so that people don't post bad benchmarks of us. Comparing C Ruby to JRuby, C Ruby exhibits very little warm-up. Its peak performance is immediate, while JRuby has a slower startup time. However, our peak performance is quite decent, and we want to continue improving it.

00:02:45.130 Currently, we have to load various components during startup, including our internals, the Ruby core library, and typically Ruby gems, which involves loading thousands of Java classes. For example, JRuby 1.7 will load around 6,700 Java classes during startup. Also, since we're a Java program, the JVM itself starts slow and warms up over time, which affects our lexer, parser, and interpreter, slowing down our startup time further.

00:03:51.890 We have explored ahead-of-time compilation in the past and are looking into it again. Kevin Menard will give a talk this afternoon on the Substrate VM, which is another ahead-of-time technology that Oracle is working on. We're also evaluating a commercial project called Excelsior Jet. What ahead-of-time compilation does for a Java program is translate Java to a native executable, thus decreasing the overhead associated with class loading. By providing a test program, Excelsior Jet studies which components can be optimized, putting those optimizations into the executable.

00:04:41.790 In our worst-case scenario with JRuby, executing 'gem list' incurs a lot of compilation because nothing really warms up, and most methods are invoked only once. Loading around 200 gems with default options takes about three and a half seconds. By disabling some optimizations using the '--dev' option, we can reduce this to about two seconds. With Excelsior Jet, we've seen the time drop to about 1.75 seconds, and the Jet team has reported even better performance, so we are examining the reasons for this difference.

00:05:36.910 Moreover, we aim to get a community license for Excelsior Jet, which may allow users to install an optimized JRuby CLI that would replace the existing JRuby executable with a faster startup version. While we find these developments promising, we've learned that JRuby generates many classes after starting, which Jet cannot compile ahead of time. If we can translate those to be pre-generated at runtime, our results should improve.

00:06:07.800 Looking ahead, Jet 13 will improve performance by reducing the loading of infrastructure code when it starts, which we anticipate will help significantly. With those adjustments, we are optimistic about doing 'gem list' in under a second, while MRI does it in about 0.5 seconds, so we are getting close.

00:07:05.310 Next, let's address the warm-up time and how we hope to make it faster. When you load a Ruby method, we convert it into internal Ruby bytecode for interpretation. If the method is called multiple times (around 50), we translate it to Java bytecode, which the JVM interprets. If the code continues to be called frequently, the JVM compiles it down to native code.

00:07:48.890 Though we achieve good peak performance, we do encounter challenges. The issue arises with the additional code generated during warm-ups, which can obscure performance goals.

00:08:01.410 To tackle this, we're working on a new profiler that will help detect 'hot' code and optimize it more effectively. By sending less code to the JIT, we can prioritize what's truly important, enhancing our warm-up performance. We have been focusing on optimizing blocks and numeric methods, where we believe we can achieve significant improvements.

00:09:34.050 As we integrate this new profiling mechanism, we hope to reduce the JIT overhead significantly. Current benchmarks indicate that JRuby can reach up to eight times the performance of C Ruby in certain scenarios. There are still patterns in Ruby, such as dynamic method calls, that we need the JVM to handle better, and our forthcoming work with the Graal JIT should enable us to optimize Ruby operations more effectively.

00:11:20.380 Next, let's turn to our ongoing difficulties with compatibility. All software presents challenges, but Ruby, being extensive, is particularly complex. We aim to accurately reflect our compatibility work without directly criticizing C Ruby.

00:13:41.210 One significant issue we encounter is the lack of complete specifications between the Ruby spec and MRI's internal test suite. For instance, we conduct at least a million expectations and assertions during our tests, yet still manage to receive several bug reports weekly about perceived incompatibilities with C Ruby.

00:16:56.770 A recent example involved the amyl store, where users experienced unexpected behavior within transaction blocks while managing string encodings. We recognized the intricacies that need to be addressed consistently to maintain compatibility. Bugs can occasionally originate from our end, but often they highlight gray areas in Ruby's specifications.

00:18:47.630 Another recent change within Ruby's master branch introduced the inability to return at the top level of scripts. This was initially implemented incorrectly, leading to ensure blocks not executing under certain conditions—definitely an issue that needed resolving.

00:19:53.080 The integration of C code into JRuby presents several challenges, particularly when direct pointers or structures used in MRI have no equivalent in Java. We must navigate the differences between how Ruby handles system calls and how Java abstracts such operations.

00:21:15.270 A significant part of our effort—approximately 90%—is dedicated to compatibility, dealing with edge cases that everyone faces on their path to a stable implementation. We are encouraged that the Ruby 2.4 support is largely done, making way for greater focus on performance improvements.

00:23:09.760 The C extensions frequently present roadblocks, as they can heavily depend on MRI's C implementation. However, we are seeing a growing number of JRuby-compatible extensions developed, and the ecosystem continues to expand.

00:24:56.170 The future direction involves creating a façade API to mirror MRI function calls while actually executing within the JVM, making it easier for developers to port their extensions seamlessly.

00:27:39.820 As for available resources, we currently only have two full-time developers. We appreciate all the support we've received and hope to see further growth in our volunteer and contributor base.

00:28:48.530 For anyone interested in contributing, there's plenty of room across different aspects, whether it's Ruby, Java, or enhancing our documentation and response systems.

00:30:32.950 We encourage Ruby developers to contribute by either fixing bugs directly or experimenting with their Ruby code. Our aim is to gather feedback and continue to improve JRuby for everyone's benefit.

00:32:16.620 Finally, we’d love to hear from you about your experiences with JRuby. This feedback helps us tremendously.

00:32:39.600 Now, do we have any questions? Thank you for your attention.

00:35:03.090 Yes, do we have a few questions? Any questions about the work we’re doing?

00:35:33.140 One answer to a question asked mentioned refinements. We are indeed working on making refinements compatible with JRuby.

00:36:09.030 About collaboration, we've been working together for years and consider it essential to have aligned interests and values. Our shared experiences have enabled us to navigate conflicts smoothly.

00:39:43.600 As for packaging JRuby applications, we recommend packaging them as you would a typical Ruby application, leveraging tools like Warbler, which can create runnable JAR files, or using other solutions suited for JVM.

RubyKaigi 2017