JRuby: The Road to Ruby 2.6 and Rails 6

Talks

Charles Nutter

#java-virtual-machine-jvm

#performance

#database-performance

#concurrency

#ruby-implementations

JRuby: The Road to Ruby 2.6 and Rails 6

by Charles Nutter and Thomas E Enebo

The video titled "JRuby: The Road to Ruby 2.6 and Rails 6" features Thomas E Enebo and Charles Nutter discussing recent developments and future plans for the JRuby project, particularly in relation to supporting Ruby 2.6 and Rails 6. The speakers highlight their commitment to maintaining JRuby as a close alternative to CRuby while leveraging the benefits of the JVM.

Key points discussed include:

- JRuby's Background: The project has been ongoing for 11 to 12 years with support from various sponsors like Red Hat and previously, Sun Microsystems.

- Compatibility and Performance: JRuby aims to be a drop-in replacement for CRuby, ensuring that pure Ruby gems function correctly. Recent improvements in compatibility for features like refinements (achieving 99%) and ongoing work to enhance enums and fibers are highlighted.

- Current Work on JRuby: The team has developed a Ruby 2.6 branch and shares their considerations about timing the release of JRuby 2.6 support against future Ruby releases. A significant focus is on refining internal load and require logic to improve startup times.

- Challenges with Startup Time: The speakers explain the inherent difficulties with JRuby’s startup speed, particularly in comparison to CRuby, due to differences in how they execute code. Solutions such as class data sharing and new JVM features are being explored to mitigate these issues.

- Real-World Applications: JRuby is successfully deployed in production environments, particularly in Java-based infrastructures like banks and government agencies, demonstrating its viability for large-scale applications. Benchmarks suggest that JRuby is approaching key performance metrics for real-world Rails applications.

- Ongoing Optimization: Efforts continue to focus on benchmarking, performance, and memory management for JRuby applications. The speakers encourage the usage of testing tools to facilitate effective migration from CRuby to JRuby.

- Community Engagement: Encouragement is given for developers to contribute to JRuby by leveraging available resources and understanding migration strategies to adapt their applications effectively.

In conclusion, while JRuby is facing challenges, its ongoing development and optimizations make it a worthy consideration for developers seeking a Ruby implementation on the JVM, especially for Rails applications. The continual enhancement of JRuby's compatibility and performance reflects a commitment to ensuring its competitive positioning within the Ruby community.

00:00:01.190 All right, we will get started and let folks filter in here from lunch as we get going.

00:00:07.560 We're going to give you a little update on where we stand with JRuby, how things are looking in terms of compatibility and performance, and how we are getting ready to support Ruby 2.6 and Rails 6.

00:00:14.820 We are the JRuby co-leads, and we've been working on this project full-time for 11 to 12 years now, which is kind of amazing.

00:00:21.510 We've had sponsors like Red Hat who have been willing to keep this project going. In the past, we were very happy to have Sun Microsystems support a lot of our efforts. So, we are really excited about being able to continue to work on JRuby.

00:00:35.579 Before we continue, I want to mention something important. A good friend of ours, one of the earliest contributors to JRuby, has been arrested and is currently on a 90-day pretrial detention in Ecuador. He was a friend of Julian Assange, which apparently was enough for them to haul him away. He lacks evidence against him, and it’s really a horrible and illegal holding of a good friend of ours. Please search for 'Free Our Beanie' on Twitter, where you can find support groups and fundraisers to help get the word out.

00:01:14.220 Alright, so what is JRuby? I'm guessing most folks here probably have some pretty good idea of what JRuby is, but it's important to emphasize that we want JRuby to be as much of a drop-in replacement for CRuby as possible.

00:01:30.630 We strive to keep compatibility solid and to ensure that all pure Ruby gems work well or have extensions available. We also try to keep a JRE version and want to be a Ruby implementation.

00:01:44.189 Yet, we also have the benefits of running on top of the JVM, which provides the power of great garbage collectors, native kits, and everything else.

00:02:01.170 Let me go over the roadmap of where we're at with JRuby. In the master branch, we have the 9.2 series that supports Ruby 2.5. Last week, we released version 9.2.7. I'll talk about one feature that came with 9.2.7, and next month we plan to release 9.2.8.

00:02:20.770 We've decided to retire JRuby 9.1, which was our 2.3 support. We now have a Ruby 2.6 branch. We are currently pondering whether we should put out Ruby 2.6 support or wait for the next significant release that will presumably be Ruby 2.7.

00:02:41.890 We actually do have a precedent for this: we skipped Ruby 2.4 without many complaints. The reason we want to wait is that we want to spend more time enhancing and making JRuby better. Having multiple support branches consumes a lot of effort.

00:03:06.820 Recently, while working within the 9.2.7 time frame, we've done a large amount of work to get refinements working properly again. We've started to see them appear more often and in key libraries we intend to support. It was necessary for us to catch this up.

00:03:40.370 In JRuby 9.2.7, which we released a couple of weeks ago, refinements are nearly perfect. There are only a few minor errors in the CRuby test refinements script, but these are odd edge cases that almost no one ever encounters. For that release, we were in the 99% range of compatibility with refinements.

00:04:09.330 We’ve also made further improvements to enumerators and fibers—specifically, enumerator dot next, which uses fibers under the hood. Up until the 9.2.8 release, enumerators had their own implementations of fibers and had some bugs that needed repair.

00:04:40.370 Additionally, we are working on reducing the overhead of fibers and are closely examining a new project from the OpenJDK called Project Loom. This will bring real native co-routines and fibers to the JVM, allowing us to spin up thousands or even hundreds of thousands of fibers like you can in CRuby without needing to back each one with a native thread.

00:05:17.840 The final significant project we are currently undertaking is a reboot and rewrite of our internal load and require logic. This is motivated by a desire for improved startup time. We have been doing too much work while performing file searches for requires and such.

00:05:49.890 There is a cache in CRuby that’s been around for years and speeds up loading, and we’ve never implemented a similar cache in JRuby. Also, projects like Siterelated are doing excellent work in bringing more formalized code loading and reloading to Ruby applications.

00:06:12.830 We really need to fix up some features in JRuby related to autoload and elsewhere, especially with respect to Rails compatibility and performance. It’s going to take some time, but we should have all of the require and load issues resolved within the next couple of releases.

00:06:45.080 One of the main reasons people face difficulties adopting JRuby has always been the startup time. We aim to be a drop-in replacement for CRuby, supporting the same command-line tools, server frameworks, and development flows that developers are used to.

00:07:15.280 This becomes quite challenging when we have startup time issues in applications because running quick migrations or rake tasks often takes considerably longer in JRuby.

00:07:43.290 For the past twelve years, we have been continuously working to improve startup time. Currently, this is a sort of state of the art for where we stand.

00:08:06.650 Why is this such a difficult problem for us? CRuby benefits from the fact that all the code running when you start booting an application is written in C. The parser, compiler, and interpreter for those instruction sequences are mostly hot and fast C code.

00:08:50.720 In contrast, JRuby executes on the JVM where everything begins cold. The JVM has to interpret everything as bytecode before it turns into native code. So, while JRuby can speed up operations significantly when repeated in the same JVM, the initial startup time is less than optimal.

00:09:18.540 We are working on various strategies to address this issue. A few graphs illustrate our current situation compared to CRuby. As presented, the timings reveal that CRuby is generally considerably faster.

00:09:51.300 By switching to more severe benchmarks, such as running a gem list command on a local JRuby repository, we start to see the JRuby runtime struggles. Booting JRuby parts written in Ruby takes longer because everything starts out cold.

00:10:27.170 Even for a basic command like '-e 1', this shows how significant the cold start effect is with JRuby; we see that it easily exceeds a second. However, if we set JRuby to run multiple times within the same JVM, it performs significantly better as the JIT optimization begins to kick in.

00:10:58.300 Another interesting measure involves executing gem version commands, which load various Ruby gems necessary for the version information. This consumes considerable time due to the overhead involved in loading all that information.

00:11:26.920 It’s important to note that gem list commands are among our worst cases because this involved primarily a lengthy series of eval calls and does not allow for JIT optimization.

00:11:59.480 As you see from these benchmarks, the 10th iteration starts to get closer to the CRuby numbers. We are seeking ways to get the JVM to pre-optimize this in the future. Over the years, we've had various workarounds, including disabling our JIT to improve startup times.

00:12:34.030 Running on Java 11 has also introduced new features that significantly impact our startup time, resulting in higher initial delays.

00:12:47.940 But using options like class data sharing allows the JVM to preload parts of JRuby, contributing to a shorter startup time. OpenJ9, a new open-source JVM from IBM, supports 'QuickStart' mode that aims to reduce boot time significantly.

00:13:16.950 All in all, while we're pleased with the timeline of optimizations, we recognize that we’re still at a disadvantage relative to CRuby and will seek to make further improvements.

00:13:51.050 To summarize: while we do see improvements, there are still challenges and future opportunities while utilizing JRuby. Moving into large-scale applications, like web development, is a major focus for JRuby, especially with Rails.

00:14:27.740 Many companies are deploying JRuby in production, running entire sites efficiently on clusters that range from 30 to 50 machines, particularly in environments like government institutions and banks.

00:15:06.920 As these features evolve, JRuby on Rails enhances the efficiency of many applications, particularly where existing infrastructure is primarily Java-based.

00:15:35.530 The focus on managing memory usage effectively is a defining characteristic of JRuby, allowing users to handle high traffic volumes by leveraging enhanced threading features.

00:16:02.240 These performance benchmarks on a simple scaffolded Rails application at the full-stack level demonstrate the ongoing challenges we face and the steps removed from CRuby.

00:16:36.320 However, recent optimizations over the past year show that JRuby is now convincingly viable for real-world Rails applications.

00:17:05.540 Some recent tests revealed that the JRuby performance is approaching optimal ranges for simple applications, structured around the active record and related to database overhead.

00:17:43.150 Acknowledging the importance of optimization, we aim to ensure that JRuby runs successfully with a stable structure, which will positively influence long term solutions.

00:18:19.230 As we work on performance, understanding how various external benchmarks and associated tools impact overall performance is vital. Each benchmarking process introduces its own quirks, especially regarding concurrent requests.

00:18:57.420 Issues related to connection management, particularly in how tools handle HTTP connections in relation to place a significant mark on overall benchmarks.

00:19:26.040 Using different benchmarking tools yields varied findings and allows for critical assessments in testing configurations.

00:19:55.100 To underscore the importance of detailed testing, issues with keep-alive functions were explored that showed inconsistencies in behavior through different modules.

00:20:23.050 In summary, the evaluation of JRuby remains ongoing with active efforts to ensure it remains a competitive solution for Rails applications moving forward.

00:20:52.280 We also dealt with some key intricacies associated with resident memory, particularly with JRuby just requiring a fraction of the memory needed in equivalent CRuby setups.

00:21:23.640 This innovation paves the way for looking into additional production complexities that arise in full deployments.

00:21:54.050 Having the opportunity to benchmark JRuby against larger applications offers insights for other developers considering JRuby for their own projects.

00:22:22.950 This discussion leads to important considerations on strategies that can improve JRuby deployments.

00:22:55.340 Integration with larger applications, such as RubyGems.org, faced its share of challenges in effectively folding into production.

00:23:23.270 However, incorporating foundational tools and configuring benchmarking appropriately allows for clearer assessments of JRuby, helping trace its ongoing viability.

00:24:03.950 As we near the end of our benchmark presentation, the focus shifts towards how JRuby manages Rails applications to ensure efficient method calls. Understanding the implications of memory usage contributes significantly to developments moving ahead.

00:24:43.530 The final chapter outlines the critical need for careful management of systems to avoid common pitfalls that can negatively influence performance.

00:25:34.760 We delve into the different approaches existing for users who wish to move from C Ruby to JRuby, including the installation of the JRuby lint gem.

00:26:21.240 This analysis will yield comprehensive reports for users highlighting incompatibilities present in their code or gems.

00:26:54.550 Going through the report allows developers to identify problematic gems and how they might need to adapt.

00:27:29.830 Ultimately, common strategies can provide routes to address notable challenges, enhancing JRuby compatibility.

00:28:07.660 The trending focus remains on gradual migration to JRuby, ensuring new developments remain integrated effectively within the larger Ruby community.

00:28:46.880 So, as you pursue any migration, keep in mind that adding platform tags, writing pure Ruby, utilizing FFI libraries, or developing Java native extensions will significantly enhance processes and interactions.

00:29:31.240 The aim is for Ruby developers to embrace JRuby through seamless adaptation and community engagement.

00:30:16.840 As we approach the conclusion of this discussion, we emphasize the uptake of JRuby across various gems as community efforts yield good progress.

00:30:54.220 The ongoing work conducted by contributors will remain on full display as we encourage other developers to equally explore this rich landscape.

00:31:23.690 To conclude, addressing scales of practical use with JRuby against Rails enables developers to keep a watchful eye for best practices that could enhance performance within their own applications.

00:32:15.640 I want to thank everyone for joining this presentation. We'll open up for questions to better understand any particular aspects you might want to discuss further.

RubyKaigi 2019