Ruby Video
Talks
JRuby: Looking Forward
Charles Nutter
@headius
#jruby
#java-virtual-machine-jvm
#performance
#garbage-collection
#concurrency
#fibers
#android
Summarized using AI

JRuby: Looking Forward

by Charles Nutter

In this talk titled "JRuby: Looking Forward," presented by Charles Nutter at RubyKaigi 2023, the speaker shares an in-depth outlook on JRuby, a Ruby implementation on the Java Virtual Machine (JVM). Nutter, who has extensive experience in JRuby development, emphasizes the project's commitment to high compatibility with Ruby while providing unique features offered by the JVM.

Key Points:
- JRuby Basics: JRuby has been around for over 15 years, aiming to provide a pure Ruby experience while leveraging Java's capabilities. Nutter assures that most Ruby code will work seamlessly on JRuby.
- Compatibility and Versions: Currently, JRuby 9.4 aligns with Ruby 3.1, showcasing excellent compatibility. The team is also gearing up for JRuby 9.5, which will introduce enhancements and support for Ruby 3.2.
- Performance: A significant aspect discussed is performance, including startup time, garbage collection, and JIT compilation. The speaker acknowledges user complaints regarding slow startup times compared to CRuby and outlines strategies for improvement, such as using the '--dev' flag to optimize performance.
- Future Developments: The presentation highlights several projects that will enhance JRuby's capabilities, including Project Loom for lightweight threading and Project Panama for improved native library integration.
- Deployment and Scalability: Nutter illustrates JRuby's advantages in server deployment, particularly its efficiency in using memory and threads compared to CRuby, promoting better performance in multi-threaded applications.
- GUI and Mobile Support: The capabilities of JRuby in developing cross-platform applications using GUI libraries like Swing and advancements in Android support with Rubato were also covered.
- Community Engagement: Nutter encourages the audience to engage with JRuby, try out the latest versions, and provide feedback, underscoring the importance of community in advancing the project.

In conclusion, Nutter expresses optimism about JRuby's future, particularly with new features and optimizations on the horizon, positioning it as a vital tool for Ruby developers. He invites attendees to experience JRuby's advancements firsthand, asserting that it holds immense potential for varied applications across different domains.

00:00:02.959 Okay, let's get started. I've got a lot to cover today. I'm going to talk about JRuby and some of the cool stuff we have coming up in the future.
00:00:11.340 I'm Charles Nutter, but you can call me Charlie. That's fine with me. Here's my contact information. I've been doing JRuby development for a long time now, over 15 years, and I'm getting close to 20 years.
00:00:18.060 I've been doing full-time JRuby development since about 2006, first with Sun Microsystems, then Engine Yard, and of course, for the last 10 years, we've been thankful that Red Hat has continued to sponsor the work we're doing to make JRuby better.
00:00:36.300 So, what about JRuby? How many people here have never heard of JRuby? Okay, there's a few folks. Good! There'll be a lot of content here for everybody, whether you're new to JRuby or already familiar with it. JRuby is Ruby on top of the Java Virtual Machine (JVM). We always aim to be a Ruby implementation first, so we focus on user experience, command line functionality, and compatibility with Ruby, while integrating with the JVM as a secondary feature.
00:00:54.780 We expect that any pure Ruby code out there should just work on JRuby. If anything doesn't work properly, let us know. We have a very high level of compatibility. However, there are different extension APIs; we don't support certain C extensions that regular Ruby does. We also don't support forking, because the JVM doesn't allow it. Fortunately, we do have parallel threads, so that's something to consider when building an application.
00:01:19.500 JRuby has been in use for a long time, over 15 years, with production users from thousands of companies all over the world. We are very excited about our success in that regard. I want to take a step back and ask what is really important for a Ruby implementation. Of course, everybody always talks about performance, garbage collection, or straight-line execution, but there are many other important aspects.
00:01:40.320 Usability aspects are crucial: compatibility, startup time, user experience—how does it feel to use? Runtime features matter as well, such as garbage collection and Just-In-Time (JIT) compilation. Tooling on the platform and the platform features themselves, like building and deploying server applications or desktop applications, all play a role.
00:02:01.140 Performance is indeed important, and it has many different dimensions, including straight-line performance and scaling across various resources. All of these factors play into applications in different ways. Getting started with JRuby is quite easy. You can visit our website at jruby.org for more information.
00:02:20.280 Generally, there are only two steps: install a Java Development Kit (JDK) and then use whatever Ruby installer you're accustomed to—be it Ruby Install or RVM. That’s the quickest way to get up and running with JRuby. You can also download the tarball we ship, unpack it, and have JRuby running on your system.
00:02:45.180 Let's take a look at JRuby with Interactive Ruby (IRB). We can call into some Java libraries here. For example, we can use the Java Lang Runtime class to get an instance of the runtime, ask how many processors are available, how much memory is free on the system, and so on. Now we’re up and running in JRuby.
00:03:10.920 The most important aspect for us is compatibility. Currently, we have JRuby 9.4, which is compatible with Ruby 3.1. We released it about four months ago, around the time of RubyConf in the U.S. Compatibility levels are generally very good; we are still addressing a few edge cases, but most users are happy with its performance.
00:03:26.820 JRuby 9.3 will be maintained for a while with Ruby 2.6 compatibility, but I assume most people have moved beyond that by now. For instance, Rails 7 requires Ruby 2.7 or higher, so we're somewhat constrained by that decision. Later this year, we’ll be working on JRuby 9.5, which will include many new optimizations and Ruby 3.2 compatibility.
00:03:51.840 Here is a chart created by Benoit from the Truffle Ruby project, showing the compatibility levels based on Ruby specs—how many Ruby specs we can pass. We're happy to report that JRuby ranks very high for compatibility with command-line features and language features.
00:04:17.580 Currently, we are about 98% compatible. Some features, like flip-flops, remain unimplemented, as I want to see if anyone files a bug report about it—so far, no one has had an issue with that. We do have high compatibility with the core libraries as well. The standard library shows slightly lower compatibility due to several C extensions we don't support, but for the non-C extension libraries, we cover those excellently.
00:04:47.520 Another aspect of usability that we often have concerns about is startup time, which is probably the number one complaint from people using JRuby. We are fighting an uphill battle here as the JVM just isn’t designed for quick startup. Most core JDK classes start out interpreted in the JVM, and JRuby makes this a little worse by parsing all the Ruby code with our interpreter, which in turn is interpreted on the JVM.
00:05:10.110 Our Ruby compiler is also interpreted by the JVM. Eventually, things get up and running as we turn it into bytecode, which the JVM JIT compiles, but this process takes time. Here’s a more graphical representation of the current architecture of JRuby.
00:05:31.680 JRuby pulls in Ruby code on the left side, which goes into our parser and compiler, getting transformed into Ruby intermediate representation, which we interpret for a while. Once the code heats up sufficiently, we compile it into JVM bytecode, utilizing features like invoke-dynamic to optimize performance. The JVM then takes over and runs through its optimization cycle.
00:05:56.520 The result is a significantly slower startup for something simple, like a 'hello world' command, taking over one and a half seconds compared to what C Ruby would do in about 53 milliseconds. This obviously isn't ideal. One of the first ways we've tackled this issue is by simply doing less of these optimizations, getting to the final stage more quickly.
00:06:22.920 This is where we have JRuby's Dev mode. You can pass the ‘--dev’ flag to JRuby, which simplifies JIT and tunes the JVM’s JIT to be a bit less aggressive, helping speed up some command-line operations.
00:06:38.520 Here’s a test with the 'hello world' command using the ‘-E1’ flag. This results in a 25% improvement in startup time, and it has an even greater impact on longer-running commands. For example, JRuby generating a Rails application shows a significant improvement—over 50% faster with the ‘--dev’ flag.
00:07:03.180 We are also exploring the possibility of ahead-of-time (AOT) compilation for the JVM or Java platform. The GraalVM native image compiler is one of the well-known methods for achieving faster startup, as it’s what Truffle Ruby uses.
00:07:28.740 Additionally, we’re looking forward to a project called Leiden from the OpenJDK team, which will provide a more standardized method of AOT compilation. This will allow JRuby to maintain new code running and re-optimize it while improving startup time for small commands.
00:07:52.920 Here's an example from Truffle Ruby in their JVM mode, which registers a startup time of 2.3 seconds using their native executable and some additional optimizations, making it even faster than C Ruby's startup. However, we still have to load and interpret Ruby code, and optimize it, which contributes to longer startup times.
00:08:17.880 When considering longer-running commands, our ‘--dev’ flag is actually better at cutting down startup time compared to native compilation. Thus, we have to find the right balance when speeding up startup time.
00:08:42.180 Additionally, the last area we are exploring for improving startup time is 'snapshotting.' There is a feature in Linux called checkpoint and restore in user space, which is now starting to integrate into JVMs such as IBM’s Semaru version. We have also built a working prototype for JRuby that takes advantage of checkpointing and restoring, which speeds up JRuby.
00:09:05.760 The idea is to start up the JVM, perform some operations to warm up JRuby so that it compiles itself, and saves a snapshot. From this point onward, every time we start JRuby again, we will begin from this checkpoint with an already warm virtual machine, resulting in faster startups.
00:09:29.040 For a quick test with JRuby using checkpointing for a simple 'hello world' command shows significant improvement, bringing the startup time competitive with that of C Ruby. The same performance can be observed when generating larger commands like creating a new Rails application, effectively reducing startup time under a second.
00:09:54.960 Now let's discuss some of the runtime features that make JRuby particularly interesting. We have access to all the JVM garbage collectors (GCs), and new ones are continually emerging. These GCs can be tuned in various ways depending on your needs.
00:10:23.160 If you want fast allocations, you can use the parallel garbage collector. If you're handling a large amount of data, you might consider G1 or ZGC, which are designed to manage old data efficiently in memory while minimizing pause times during garbage collection.
00:10:49.020 Many of these GCs are built into OpenJDK and can be easily used with JRuby by simply passing a flag. One great tool available for monitoring is Visual VM, which shows a live view of the garbage collector's activity.
00:11:14.340 You can view CPU usage, the number of loaded classes, threads, and monitor garbage collector generations to see how memory management is functioning in real-time.
00:11:40.260 The JVM also has a world-class Just-In-Time (JIT) compiler called HotSpot, which is widely deployed. This JIT provides various optimization tiers for quick performance improvements initially, before applying more aggressive optimizations down the line.
00:12:00.720 Currently, we’re experimenting with the Graal JIT, which can be plugged into the JVM for more aggressive optimizations—especially beneficial for numeric algorithms—leading to substantial speed improvements for JRuby.
00:12:28.920 In addition, there are other JVMs like OpenJ9 (IBM Semaru) that have their own JIT optimizations, allowing users to save compiled classes to disk, improving execution speed for subsequent runs.
00:12:54.900 Moreover, monitoring and profiling are essential aspects. Apart from Visual VM, the Flight Recorder feature of the JVM, driven through a GUI application called Mission Control, provides a wealth of insights.
00:13:18.840 In Mission Control, you can select the JRuby application to start a recording. Once the recording finishes, you will see allocations, helping you identify excessive object allocations, trace them back to specific lines in Ruby code, and monitor thread activity.
00:13:41.280 One of the exciting features coming to the JVM world is Project Loom. Historically, JRuby has implemented the Fiber class, but without the ability to control the call stack on the JVM, we had to simulate fibers using native threads.
00:14:04.080 This approach faces challenges, especially with trying to spin up thousands of fibers, as most systems cannot allow that much resource consumption. Project Loom brings native fibers to the JVM, allowing us to offer lightweight threading and fiber support in JRuby.
00:14:27.840 A benchmark demonstrates the problem with the existing fiber approach. For example, if I create 100,000 fibers that immediately yield, running them along JRuby results in an overload of threads, potentially crashing the application.
00:14:51.720 With Loom's support integrated currently into JRuby, this shifts things significantly. We appreciate how easily these fibers can start, resume, and complete tasks in a very short amount of time. This has opened up new possibilities for us.
00:15:14.760 Historically at RubyKaigi, Samuel Aitkins presented his vision for handling a tremendous number of sockets simultaneously—100k or 1 million K within a single Ruby process. With the update on Loom, we can achieve this now.
00:15:35.520 Also, I look forward to implementing async IO and the complete stack in JRuby to support Falcon servers, which could potentially be a significant area for contributions.
00:15:56.520 The final runtime feature I want to mention is Project Panama, which is progressing well and will allow us to call native C libraries directly from the JVM.
00:16:15.840 Currently, JRuby utilizes a foreign function interface (FFI), permitting access to POSIX libraries. With Panama, JVM will optimize calls to these libraries, enhancing performance. This will significantly change how we interact with native libraries.
00:16:38.640 Panama also provides a foreign memory API, allowing for more efficient usage of off-heap memory. What's most exciting is a tool called JExtract that automatically generates binding codes from header files.
00:17:02.280 This means by pointing JExtract at a header file, it can generate the JNI bindings required, making native library calls simpler and faster than before, thus improving our development experience.
00:17:27.840 We are excited to implement this approach with our SQLite JDBC adapter, which, through previous methods, faced performance penalties operating via the Java Native Interface (JNI). A proof of concept using Panama indicates a promising double performance improvement.
00:17:52.680 We are also working on integrating YARP—Yet Another Ruby Parser—into JRuby. This project has been discussed, and following this talk, Kevin will delve deeper into YARP. As there are many AST nodes that we have already integrated into JRuby, early tests indicate about a 20% improvement in startup speed compared to the current JRuby parser.
00:18:16.860 On that end, we are still utilizing JNI, and once we bring Panama into play for YARP, it should streamline our efforts even further for straightforward native library access.
00:18:41.940 Now, let’s consider GUIs. A real advantage of the JVM is the support for numerous cross-platform GUI libraries. The most well-known is Swing, a set of Java widgets for desktop applications that is consistently available across platforms.
00:19:07.260 There’s also the Scalable Windowing Toolkit (SWT), part of the Eclipse project. This allows for native widgets when creating desktop applications, making them look more like standard applications across different OS platforms, including macOS.
00:19:33.960 Then, there is JavaFX, a scene builder GUI library used for building modern applications. It requires a few more libraries to pull down, but it’s worthwhile.
00:20:01.560 We also have a JRubyFX project that allows you to wrap JavaFX with Ruby code, making application development easier for Rubyists. With other wrappers like Shoes and Glimmer, building cross-platform applications has never been simpler.
00:20:30.480 Aside from desktop applications, remember that most of us carry graphical computers in our pockets through our Android phones. We are updating Rubato, JRuby's support for Android, providing tooling and wrappers for Android APIs.
00:20:55.200 Rubato allows you to build applications wholly in Ruby. A classic example showcases Rubato IRB, an interactive Ruby shell running on mobile.
00:21:19.920 We previously couldn't publish our application due to excessive permissions but are working within new security requirements to republish it soon. Until then, users can manually install the APK.
00:21:46.560 Currently, we're upgrading Rubato IRB to JRuby 9.4, ensuring Ruby 3.1 compatibility, and we're making significant progress throughout the application.
00:22:07.200 To wrap up, I'll discuss performance and scaling. Deploying applications in CRuby has historically faced the issue of a lack of concurrent threads and parallelism at the operating system level. This necessitates worker processes, resulting in resource inefficiencies.
00:22:35.880 You can utilize techniques like copy-on-write and pre-loading servers to mitigate some overhead. However, JRuby presents a better solution compared to CRuby, allowing multiple users to run on a single server process without wasting memory.
00:23:01.560 In a benchmark involving a basic Rails application, we generated a blog post and tested concurrent requests using both JRuby and CRuby with different threading methods.
00:23:19.320 Here with JRuby, I was able to run 16 threads for 16-way concurrency, compared to set worker limits in CRuby. The results indicated that JRuby generally achieved better performance.
00:23:39.660 Even with a warm-up time evident for JRuby, several requests started generating results at higher requests per second once stable. The warm-up curve is more extended, but it surpasses performance expectations.
00:24:02.040 Yet memory usage remains a critical aspect. By default, the JVM utilizes memory aggressively, resulting in JRuby using around 3.5 gigabytes. However, we can configure it to optimize memory, which reduces our memory footprint.
00:24:31.680 By limiting the JVM's heap size to approximately 300 megabytes, we found JRuby drops below one gigabyte of memory usage, relative performance doesn’t degrade much during this tuning.
00:24:55.560 For CRuby setups, the 1.6 GB without YJIT or around 2 GB with YJIT reflects considerable memory consumption without optimal scaling. Nonetheless, we can adjust our instances and optimize costs effectively.
00:25:20.760 The key takeaway is to maximize usage efficiency and lower costs while achieving better overall performance. This reflects significant savings in cloud service costs as well.
00:25:41.400 In conclusion, JRuby 9.4 continues to stabilize, and we are excited about the global production adoption. Please give it a try and provide feedback. As we catch up on compatibility, our focus will also shift back to optimizations after several years.
00:26:01.320 With JRuby 9.5 expected later this year, we'll integrate Ruby 3.2 features while aiming for another round of optimizations. I hope this has illustrated how many aspects of JRuby and the JVM we're starting to leverage.
00:26:32.220 With projects like Loom and Panama, combined with mobile development support and plenty of opportunities for desktop app development, JRuby holds promise for diverse applications. Whatever interests you, we believe JRuby can be immensely helpful.
00:27:01.800 Thank you for your attention, and I look forward to seeing you around the conference. Also, I have a limited supply of JRuby stickers for anyone interested, so come and see me afterward.
00:27:43.440 Thank you!
Edit
Explore all talks recorded at RubyKaigi 2023
+47