JRuby: Not Just Another Ruby Implementation

Talks

Charles Nutter

#java-virtual-machine-jvm

JRuby: Not Just Another Ruby Implementation

by Charles Nutter and Thomas E Enebo

The video titled "JRuby: Not Just Another Ruby Implementation," presented by Thomas E Enebo and Charles Nutter at the MountainWest RubyConf 2007, discusses JRuby and its advantages as a Ruby implementation on the Java Virtual Machine (JVM). The speakers aim to clarify misconceptions around JRuby, emphasizing that while it is Java-based, it is fundamentally about enhancing the Ruby experience.

Key points include:

- Comparison to C Implementation: JRuby provides a compatible Ruby environment that also incorporates Java features, making it suitable for developers transitioning from Java. The speakers argue that JRuby can handle scenarios where traditional Ruby implementations may fall short, particularly in larger applications.
- Dynamic Language Compatibility: JRuby enhances the JVM by making Ruby a first-class language, allowing developers to utilize existing Java libraries seamlessly.
- Threading and Scalability: Unlike Ruby's green-threaded model, JRuby can exploit Java's native threading capabilities, allowing multiple threads to run concurrently across multiple cores, thus improving scalability and application performance.
- Unicode Support: JRuby resolves many Unicode issues present in Ruby 1.8 by leveraging Java's Unicode libraries, thereby providing a more stable environment for applications that rely on multi-byte character support.
- Performance Enhancements: The speakers detail ongoing efforts to optimize JRuby's performance, including potential compilation to Java bytecode and integration with HotSpot compiler optimizations.
- Integration with Development Tools: The development of tools like NetBeans to assist Ruby developers by providing features such as autocompletion and error detection aims to make JRuby an appealing choice for new projects.
- Community and Ecosystem: The importance of community contributions to JRuby's development is emphasized, encouraging developers to engage and adopt open source projects.

In conclusion, JRuby presents a significant opportunity for Ruby developers, combining the expressiveness of Ruby with the stability and performance enhancements from the Java ecosystem. The speakers invite questions and suggest that ongoing community support will help refine JRuby further, enhancing its capabilities and ensuring a promising future for both Ruby and Java integration.

00:00:08.559 All right, while Tom is getting set up, I wanted to see how many folks here have been Java developers. Not necessarily Java developers now, but have done Java development in the past.

00:00:14.960 Yeah, the majority of you. And how many of you don't want to go back?

00:00:22.240 Yeah, there's quite a few. One of the problems we've had with JRuby is trying to push the idea that JRuby is not about Java. JRuby is about Ruby.

00:00:31.840 Unlike a lot of other dynamic language implementations for the JVM, we have taken the approach of trying to make it as compatible as possible. This allows us to run all the applications that you're used to.

00:00:38.960 Hopefully, as we go through this talk, you’ll keep in mind that this is really about making another version of Ruby that has some different characteristics but can perform all the same tasks that your beloved C implementation can do.

00:01:02.559 We're going to talk a little bit about JRuby. As I saw yesterday, pretty much everybody knows what JRuby is, so we're not going to give a lot of introduction to it.

00:01:10.240 I am Charles Nutter, and this is Tom. We both work for Sun. I opted not to wear the Sun shirt today because I tend to do that a little too much.

00:01:15.759 However, we are both engineers at Sun, obviously senior staff engineers or whatever the title is, and we've been doing Java for about ten years. But we have a lot of other experience with various other technologies. We’ve both worked with different dynamic languages on a lot of different platforms.

00:01:33.040 So we come from a fairly broad background, primarily being Java developers for the last ten years. Now our goal is to try and make Ruby a first-class language on the JVM. By 'first-class,' I mean that anything you might have done in Java before, you can now do with Ruby.

00:01:57.680 We're also trying to take what we learn from working on Ruby and make the JVM a better place for all dynamic languages. The enhancements we bring to Ruby can benefit others as well. Here’s the agenda: I'm going to try and be a little inflammatory on some of this.

00:02:23.440 This is really a talk about why JRuby over the C implementation. It's not that we recommend using JRuby for everything, but there are certain scenarios where you may want to start looking at it.

00:02:40.720 First off, you know what JRuby is. It's a Java implementation of Ruby. But it's been around for about five years.

00:02:46.560 It’s open source, available under a couple of different licenses, so you should be able to use it for whatever you want. We have a really large and growing community of contributors.

00:03:03.680 We're not the actual founders of this project; we adopted it. So, adopt open source! Yes, that’s a great way to get your name out there.

00:03:09.680 It's also fun to take over something and make it your own. We're aiming for compatibility with the current Ruby version, while also adding the features of Java.

00:03:21.520 This includes being able to call Java libraries directly and call Ruby from Java easily. There are other projects also emerging based on JRuby, like the JWC-based Active Record adapter.

00:03:32.239 So these are the overview bullets for the next few slides. A lot of people wonder why you would want to run Ruby on Java, and more specifically, why you would want to run Ruby on the JVM.

00:03:47.599 The JVM isn't necessarily just about the Java language. These are the points I’m going to cover. I’ll jump into the detailed slides here. Starting off, Ruby design issues.

00:04:05.360 There are several concerns that people have with Ruby as it scales to larger applications. The threading issue is one of the big concerns; Ruby is still completely green-threaded.

00:04:29.680 This means that if you want to be able to scale it on today's machines—most of which now have multiple cores—you need to have multiple processes running. Managing these processes becomes more difficult, and communication across processes can be troublesome.

00:04:47.840 Another problem is that if you call out to a C library and it fails to return, none of your other threads will execute. You’ll be stuck because there’s no way to yield those threads unless they know Ruby internals.

00:05:12.160 Additionally, the Ruby scheduler is what they call a time-slicing scheduler but is a strict 10-millisecond time-slicing scheduler across all platforms. If you’re running on the slowest machine possible, it means 10 milliseconds per thread. On the fastest machine, it’s still 10 milliseconds per thread.

00:05:49.039 Every major operating system now has an adaptive scheduler, which results in Ruby not scaling appropriately with multiple threads on different machines.

00:06:12.240 Ruby 1.9 fixes a lot of this, but it doesn’t allow you to run those threads in parallel. It does introduce native threading, but they all wait for a large lock.

00:06:39.840 The problem with Ruby 1.9 is that even though native threading has been implemented, not all the internal libraries are safe for multiple threads. This means you cannot guarantee the integrity of the runtime when multiple threads are running in parallel. It's partway there.

00:07:06.560 The other issue with threading in Ruby 1.9 is that there’s a desire for all extensions to continue working as much as possible. Extensions are not aware of Ruby threads, which makes them not cooperate well with the threading model.

00:07:31.360 Regarding Unicode, the situation has been bad in Ruby 1.8. When we started at Sun, we were asked about Unicode support, and many were surprised by the lack of it. The reality is that Ruby has faced issues supporting Unicode effectively.

00:07:56.960 This has been a significant issue for Ruby developers, especially in communities that require Unicode, such as European communities. It wasn’t until Ruby 1.2 that a library for multi-byte support was finally added.

00:08:26.240 Ruby 1.9 introduces support for Unicode and several other encodings, but these changes are aggressive and will break a lot of APIs. This will lead to a migration period to the new string implementation because it does not work with bytes anymore—it works with characters, and counts are in characters.

00:08:54.960 The speed issue with Ruby is that while it is fast enough for some applications, it is slower than many other implementations, which often deters developers from adopting it. Many are concerned about performance and do not want to take that hit when moving to a new language or platform.

00:09:29.680 Although some implementations in Ruby may outperform C++, they are exceptions rather than the rule. In general, there isn’t much in the pipeline for performance improvements in Ruby 1.8 as it is mostly frozen.

00:09:53.920 Most of the visible improvements are expected with Ruby 1.9, which looks good in benchmarks, but it is important to note that these benchmarks are optimized without addressing the overall performance enhancements.

00:10:11.680 Also, it's unclear if there will be a full ahead-of-time compiler or if it will just run the compilation every time it starts. We don't know whether it will implement just-in-time compilation to native code or enhance the garbage collection and memory model.

00:10:45.440 Additionally, concerns arise since Ruby 1.8 will not experience major changes until we reach Ruby 1.9, which is coming later.

00:11:10.400 Memory management in Ruby is designed simply. It is based on a stop-the-world garbage collector, which leads to application pauses as it cleans up memory. Although it’s a straightforward garbage collection method, it's not optimal for complex applications.

00:11:58.800 Changes to the memory model will likely remain unchanged in Ruby 1.9, and if Ruby becomes significantly faster, the amount of garbage created will also increase, resulting in more pauses.

00:12:46.000 Extensions are another issue, as most users have written or used extensions. The situation with Ruby's extensions, while they work well in Ruby 1.8, tends to limit Ruby's flexibility.

00:13:14.960 Changing the memory model, threading, and other things can break extensions, thus slowing down the Ruby development process. Additionally, C-based extensions often lead to crashes in the Ruby VM due to memory management issues.

00:13:53.440 The long-term advice often given is to write performance-critical tasks in C, but developers prefer writing in Ruby. The politics of getting Ruby integrated into large, slow-moving organizations also pose a challenge.

00:14:50.320 There is a legacy of Java applications that may not be compatible with Ruby, but Java's vast library ecosystem gives developers a significant choice.

00:15:34.240 We’re exploring ways to leverage existing Java libraries in the Ruby space, and we’re making Ruby work alongside Java to access its functionality.

00:16:04.320 Tom will discuss how JRuby addresses some of these issues next.

00:16:29.760 In discussing JRuby, the first point to note is that Java is natively threaded, giving us the ability to run code across all cores effectively.

00:17:01.440 All core classes are now thread-safe, allowing multiple threads to operate across multiple cores and even multiple JRuby runtimes within a single process.

00:17:38.320 This changes how you design applications, knowing that you do not have to rely on inter-process communication.

00:18:01.600 The second important feature is Unicode support—JRuby is built on top of Java's Unicode libraries, allowing full compatibility with Ruby's string functionality.

00:18:39.440 Scalability and speed are critical. We’re working hard to improve our interpreter's speed and are optimistic about achieving comparable performance to Ruby 1.8.

00:19:12.960 We support preliminary YARV innovations within JRuby, which gives us promise for performance gains.

00:19:45.440 Additionally, we’re exploring compilation to Java bytecode, supporting ahead-of-time and just-in-time modes.

00:20:15.440 More recently, we've found that simply writing clean, effective code allows the JVM's HotSpot compiler to optimize the code better.

00:20:56.640 Java’s garbage collector is one of the best in the world. We leverage that to avoid memory management concerns while enhancing performance.

00:21:31.920 Java enables developers to write Java-based rather than C-based extensions, significantly reducing the risk of crashes.

00:22:09.440 By eliminating the need for excessive code, we find that Ruby sits nicely on the JVM and makes working with Java libraries effective.

00:23:00.640 One example is a Swing application using a DSL that simplifies the complexity of Java libraries.

00:23:49.440 We can write concise, user-friendly code using JRuby, creating clear syntactical abstractions that improve usability.

00:24:13.760 This is a powerful combination as we build Ruby applications on a tailored Java platform that speaks to both languages.

00:24:50.720 This collaboration captures the strengths and compensates for the weaknesses of both languages.

00:25:23.440 Next are the developments in NetBeans, a project by colleague Tor Norby.

00:25:56.000 NetBeans is making strides by integrating Ruby capabilities, including auto-completion, error detection, and efficient code navigation.

00:26:27.680 Ideally, this editor will be a comprehensive tool for Ruby and JRuby development, thus enhancing productivity and usability.

00:27:01.120 Applications can be run concurrently, exposing Ruby developers to a world of Java integration through the editor.

00:27:34.560 When we explore benchmarks, we aim to evaluate JRuby’s performance in various aspects, thereby assessing compatibility and capability across different use cases.

00:28:06.400 There is a significant focus on performance optimization according to the rules and standards established by Ruby developers.

00:28:45.760 While there’s progress, many benchmarks still emphasize that JRuby often trails behind in speed on general patterns of performance.

00:29:16.160 There remain opportunities for refinement; JRuby's collaboration with Java libraries combines the stability of Java with the expressiveness of Ruby.

00:30:03.200 Overall, we believe that with sustained effort, JRuby will improve memory efficiency, speed, and usability in managing Java integrations.

00:30:44.000 We will continue to build on the existing Java ecosystem, including writing effective wrappers for Java interfaces that also enhance Ruby usability.

00:31:32.960 In our exploration for competitive design, we’ll continue collaborating to debug and build features that can enhance the overall JRuby experience.

00:32:03.680 We welcome continual engagement from the developer community to further evolve both languages, maximizing their potential.

00:32:39.840 Moving forward, we look toward shared objectives that optimize both Ruby and Java, ensuring a beneficial future.

00:32:58.880 Our focus will remain on advancements that enable seamless integration with Java capabilities while enhancing Ruby performance.

00:33:35.680 In conclusion, we’re excited about the prospects JRuby opens for developers and the future of Ruby on the JVM.

00:34:15.200 We’ll continuously adapt and embrace innovations within JRuby to empower developers to efficiently navigate the dynamic programming landscape.

00:35:11.280 We value questions and feedback that will further lead us towards our shared vision of elevating Ruby.

00:35:46.160 We look forward to conversations that will allow JRuby to continue thriving while staying true to its community-oriented principles.

00:36:23.040 Thank you for your time, and I encourage everyone to engage with us in our ongoing journey built on community collaboration.

00:36:47.840 Feel free to reach out with any questions about JRuby’s evolution as we move forward.

00:37:04.960 Thank you.

MountainWest RubyConf 2007