JRuby 9000 Last Year, Today, and Tomorrow

Talks

Thomas E Enebo

@enebo

#jruby

#java-virtual-machine-jvm

#ruby-implementations

JRuby 9000 Last Year, Today, and Tomorrow

by Thomas E Enebo

In this talk, Thomas E. Enebo provides a comprehensive overview of JRuby 9000, a major release that marks significant advancements in the JRuby project, which serves as a Ruby implementation running on the Java platform. Enebo shares his extensive experience with JRuby, having worked on it for over a decade, and highlights the lessons learned from the release, as well as future directions for improvement.

Key points include:
- Major Updates: JRuby 9000 aligns closely with the latest CRuby versions, embraces a new runtime, and introduces a native IO subsystem, enhancing compatibility and performance.
- Runtime Changes: The new runtime, termed Internal Representation (IR), is showcased as a complete overhaul from previous versions, leading to better organization of code and easier debugging. It uses a compiler architecture familiar to developers, reducing complexity when updating or fixing bugs.
- Performance Improvements: Enebo discusses performance gains, especially in JIT compilation, despite initial concerns about startup times and execution speed. Optimizations are now more streamlined, benefiting both the interpreter and JIT.
- Code Simplification: The update led to a 10% reduction in Java code and a significant cut in Ruby code by simplifying APIs and eliminating support for older versions. However, some breaking changes faced backlash, prompting reintroduction of certain methods for compatibility.
- Development Challenges: Enebo acknowledges ongoing challenges, such as ensuring Windows compatibility and improving startup times, which they are actively addressing through potential collaboration with Oracle.
- Future Plans: The talk outlines plans for further improvements, including additional features and tools for users to migrate their code effectively to JRuby 9000 and beyond, dubbed JRuby 50,000.

Overall, Enebo emphasizes JRuby's evolution and its goal of maintaining a seamless development experience across Ruby and Java ecosystems. By strategically enhancing performance and easing transitions, JRuby aims to attract a wider user base while continuing to adapt to the needs of existing developers.

00:00:00.000 Konbanwa! We made it—it’s the last talk of the day, and we can do this. My name is Thomas Enebo, and I'm from the United States. I live in Minnesota, about as far away from the ocean as one could be.

00:00:12.330 I co-lead the JRuby project and have been working at Red Hat for the last four years. JRuby has been my full-time job, and I’ve actually been working on JRuby full-time for ten years, including my time at Sun Microsystems and Engine Yard.

00:00:30.269 It feels like I just learned Ruby yesterday. I still remember getting Dave Thomas's Pickaxe book and really getting into it. I've been using Java for over 20 years, but it feels like 60 years. That's a joke, of course! If anyone knows of any good craft beer places in Kyoto or Tokyo, please let me know.

00:00:51.559 This is not me, but I love it when people walk up and say I don’t look much like my profile picture. For those who might not know what JRuby is, I had to throw this slide in: JRuby is a Ruby implementation that runs on the Java platform.

00:01:17.520 We have two major versions: JRuby 1.7, which supports both Ruby 1.8 and Ruby 1.9 modes. You can enable this by passing a command-line option, but it will only be supported until the end of the year. The version I’ll discuss today is JRuby 9000, which tracks the latest version of CRuby, although it is currently at 2.3.1.

00:01:43.979 JRuby is distributed under three different open-source licenses; you can pick which one to distribute JRuby under. Most people tend to choose the Eclipse Public License, as it is the most permissive. I'm not going to talk about this today, but JRuby interacts very well with the Java ecosystem, making it easy to call Java types from Ruby syntax.

00:02:31.120 You can pull in a Java library and interact with it, and you can also communicate with other JVM languages. Additionally, we offer native threads, providing a bunch of bonus features on top of being just Ruby implementation.

00:03:02.849 Today, I’ll share about JRuby 9000. This talk is a retrospective covering the good things that happened as well as the challenges we faced. The key points about JRuby 9000 include our plan to follow the latest CRuby releases. We also wanted to clean up some APIs.

00:03:29.019 It had been about seven years since our last major release, and we decided to bypass Java's IO APIs completely and just call into C for better compatibility. We also completely changed our runtime since 1.7.

00:04:13.870 Following the latest Ruby has been great, and I'll show you an example. Here’s some example Java code, and in JRuby 1.7, I'm showing the implementation of the spaceship operator and Ruby string. You can see the JRuby method annotation at the top that binds Ruby methods to the Java implementation.

00:04:56.269 There are two implementations: one for Ruby 1.8 and one for Ruby 1.9, both virtually identical. The semantic differences between versions are typically small. However, on rare occasions, we accidentally used the wrong version of a method, leading to tangled results, especially when using multibyte characters.

00:05:43.690 In JRuby 9000, we managed to remove a significant amount of Java code—about 10%—because we are no longer supporting multiple versions.

00:05:57.100 We also eliminated half of our Ruby code, which simplifies the codebase. However, breaking the APIs did not yield the results we expected. Initially, we removed methods that had '19' on the end, assuming it would create a cleaner API.

00:06:17.490 Some users of Java Native Extensions pointed out that removing those methods posed problems. These extensions are similar to C extensions in CRuby but are intended for Java interop. Many developers wanted to ensure compatibility with both JRuby 1.7 and JRuby 9000, so we ended up adding back those methods.

00:07:07.870 Now, we have a single implementation but two entry points to it. Looking forward, there’s an unexpected joke about JRuby 50,000.

00:07:22.889 It started as a humorous reference and evolved into a release plan. We will expand our embedding API, allowing for methods that enable the construction of core types like a new string.

00:07:49.389 These methods will be statically portable. We’ll also introduce a tool for linting code, helping users determine whether they are utilizing only endorsed APIs or whether changes are necessary. Furthermore, documentation will be provided to guide users on compatible usages.

00:09:14.440 We recognize that we need to prepare at least a year in advance to ensure that users can update all their native extensions for JRuby 9000. This proactive approach will benefit the transition to JRuby 50,000.

00:10:08.259 In our development process, we decided to bypass Java I/O for compatibility reasons. This approach has led us to develop a good enough performance level that we haven't even bothered tuning it yet.

00:10:48.660 There was a performance issue raised recently, and upon investigation, we realized we were performing some unnecessary copies.

00:11:60.580 However, we've made significant gains in this area.

00:12:00.100 Currently, Windows users may experience some limitations as we haven't ported C code for Windows yet. Instead, they will fall back onto pure Java mode.

00:12:55.130 We do still support pure Java mode for restricted environments, like Google App Engine, where you can’t call out to C code.

00:13:36.150 As we run on Windows, we revert to the pure Java code path, which indicates that it's an area we need to work on.

00:13:58.880 We also hope to make our pure Java mode more compatible with CRuby over time; this aspect is dependent on Java's release schedule.

00:14:29.930 Our new runtime, called IR, stands for Internal Representation. It's a complete replacement of our runtime from JRuby 1.7.

00:15:23.450 We wanted a traditional compiler architecture that anyone familiar with compiler courses would recognize—terms like control flow graph or basic block.

00:15:56.000 In previous JRuby versions, we would parse Ruby to generate an abstract syntax tree and then use an interpreter to process it. Now in JRuby 9000, we generate virtual machine instructions representing Ruby semantics.

00:16:39.680 I've found this much more readable than our previous approach. Here’s an example of our instructions displayed in a tool called Ideal Graph Visualizer. The center shows a branch-not-equals instruction, and we see the control flow graph on the right.

00:17:36.830 The cool part is that after running a compiler pass, we can visualize how the instructions change, which helps us to understand the effects of optimizations better.

00:18:29.580 Software became famous with the term 'write once, run anywhere', and I want to make JRuby renowned for the phrase 'fix once, run anywhere.' In JRuby 17, if there was a bug with Ruby semantics, we had to fix it in two places: our interpreter and the IR.

00:19:39.070 In JRuby 9000, we essentially have to fix instructions rather than making multiple corrections in the interpreter and JIT.

00:20:34.220 This streamlining simplifies things. For instance, when we added a Ruby 2.3 feature, the frozen string literal pragma, we only needed to modify the IR to support it.

00:21:39.610 We optimized it with a quick change that checks if the node is frozen, creating a frozen string operand instead of just a string.

00:22:00.560 Now let’s talk about optimizing once, running anywhere. Any compiler passes or improvements we make benefit both the interpreter and the JIT.

00:22:43.090 In the past, optimizations did not effectively aid the interpreter since we would generate low Java bytecode. But now with the IR, we focus on the instructions we emit and that has improved debugging.

00:23:58.610 If we encounter issues, it's often easy to resolve by running JRuby in a pure interpreted mode while utilizing debugging tools.

00:24:20.330 Now, for a little joke: startup times in JRuby remain an area of concern, and we recognize that we have not resolved this completely.

00:25:02.160 In JRuby 17, we parsed Ruby source code to generate an abstract syntax tree, but JRuby 9000 adds a layer of instructions which results in more pre-execution processing.

00:25:49.500 We're hoping to optimize this further. We created a special interpreter that knows to navigate these instructions without further analysis.

00:26:49.080 Unfortunately, this ends up adding a 5-10% penalty, which we anticipated. We'd been exploring ways to address the slower startup, including the idea of reading and parsing Ruby source code into a stored intermediate representation.

00:27:39.930 The idea was that if the source code already existed, we could bypass parsing and build steps entirely.

00:28:46.560 However, results were not as favorable as hoped. Testing with a sample Rails application showed only a marginal improvement. While it may reduce some overhead, it didn’t yield substantial gains.

00:29:26.880 Moreover, the issue arises during development time when many associated methods are not executed immediately, which causes delays.

00:30:32.110 If our intermediate representations were more fixed-width, the execution could be executed directly. Our architect suggested implementing binary interpretation, which we might explore in the future.

00:31:19.840 We've also been able to compile Ruby to Java class files with ahead-of-time compilation. However, method size limitations have previously caused failures with large Ruby methods.

00:32:25.070 In JRuby 9000, we resolve this by only dumping persisted data into 32K chunks.

00:32:36.990 This way, we can load the interpreter efficiently and allow methods to be JIT-compiled if they are 'hot' enough.

00:33:12.300 We don't want to compile everything since it doesn't necessarily speed things up.

00:33:33.970 Regarding interpreter performance, we’ve noticed it running a bit slower in JRuby 9000. There’s a specific case where executing a source file doesn’t lead to enough JIT opportunities.

00:34:14.460 Despite initial assumptions, many applications utilize their libraries, which allows the JIT to activate; therefore, the performance impact is less severe.

00:34:58.710 We have one user where the slightly slower interpreter becomes a significant challenge, primarily due to the additional work we require to emulate a machine.

00:35:51.910 Since we're managing registers and advancing program counters, there’s overhead associated with the accesses.

00:36:35.620 Additionally, we initially designed everything to be mutable in the IR, thinking it would yield better performance by avoiding copies.

00:37:38.470 However, we’ve learned that this ineffective when modifications occur during execution. Hence, we’re gradually shifting towards immutability, which allows for better memory optimization.

00:38:50.141 Overall, my experience working with the IR has been overwhelmingly positive; it's simpler and faster to work on than previous iterations.

00:39:43.350 Adding new features is easier, and we’re streamlining our processes. Although interpreter performance may lag slightly, the benefits from JIT optimization are helping to counterbalance that.

00:40:31.410 Lastly, we're actively working on improving startup time. We've had discussions with Oracle regarding a product intended to improve Java applications, which has shown promising results with previous tests.

00:41:25.380 We are aware of startup speed being a major challenge, and we won't overlook it as we continue to refine JRuby. Thank you for your time!

00:42:18.510 If there are any questions, feel free to ask! I appreciate your interest.

00:43:27.780 I’m curious about the executable compiler you mentioned; could you elaborate on that?

00:44:37.010 The executable compiler product isn't open or public yet. They've recognized JRuby's startup time issues and understand we are a valid use case for improvements.

00:46:03.150 We are looking forward to our collaboration with them to see what improvements we can achieve as part of our project.

00:46:57.160 Any further questions? If not, thank you again! It's been a pleasure discussing JRuby with you.

RubyKaigi 2016