Charles Nutter

Rubyists work from a command line, which makes JRuby startup time a critical concern. Traditionally, the JVM has not been optimized for startup, but that's changing. This talk will explore all available options for making a heavy runtime like JRuby start up quickly, from using class data caching services like Hotspot's CDS and OpenJ9's Quickstart to ahead-of-time compilation of JRuby using GraalVM's Native Image. We'll compare approaches and trade-offs.

The MethodHandle API was added in Java 7, as a way to programmatically build up smart function pointers. Far more powerful than simple reflection, handles JIT and optimize like Java code, producing a fast, direct, type-safe callable. And the API has continued to evolve: in Java 9, you can now embed atomic semantics, array views, loops and "finally" logic, and much more. Come learn how flexible and useful MethodHandles can be!

Ruby's Strings aggregate a collection of bytes and an encoding, allowing for IO to avoid transcoding, regular expressions to execute against raw bytes, and 7-bit strings to be compactly represented. Only the last item has been adopted by Java. To make matters worse, most Java APIs depend on Java's string representation, making them incompatible with alternative languages like Ruby. We'll explore the advantages of Ruby's string compared to Java's and discuss options for improving Java's string support in the future.

JRuby has been compatible with various Ruby versions during its lifespan, ranging from the 1.6 series through today's 2.4. JRuby has supported Rails in some capacity since the 1.0 days. And at the same time, we've continued to improve performance. In this talk we'll explore JRuby's level of compatibility today and discuss the challenges of keeping up with an actively-developed language and ecosystem.

JRuby has for years routed around the JVM, to maximize compatibility with standard Ruby. We've implemented byte[]-based String and Regexp, native POSIX support, and our own mixed-mode interpreting/jitting runtime atop JVM bytecode.

With JRuby 9000, we're taking this even further. JRuby 9000 introduces a new IR-based optimizing compiler, with inlining, specialization, and other tricks applied to both interpreted and bytecode-compiled code. We've also gone fully native for much of IO and Process management. This talk will show the state of this work and how it affects JRuby and the wider JVM world.

JRuby 9000 introduced a brand new optimizing runtime, with a register-based IR and classic compiler design. Atop this new runtime, we've started to apply our own dynamic language optimizations like inlining, specialization, and more. This talk will summarize the state of our work and how it's paying off for Ruby users.

This is a talk about JRuby 9000s optimizing compiler and the work we're doing to optimize Ruby above the level of JVM bytecode. We'll also cover work to take better advantage of JVM optimizations and keep making JRuby the best Ruby implementation available.

As one of the earliest adopters of Method Handles, I've had to build many of my own tools. InvokeBinder is one of them, providing a literal (or fluent) API for Method Handles that allows site-forward adaptation, name-based argument list manipulation, and many bonuses usually too complicated to write by hand. I'd like to demonstrate its features and enlist others to help me improve it.

JRuby 9000 represents the biggest-ever leap forward for JRuby. Not only have we caught up on compatibility (9000 will be 2.2-compatible from release), but we've completely redesigned our JVM-based runtime and have opened our codebase up to the JRuby+Truffle research project from Oracle Labs. The changes we've made will make it easier to keep up with MRI on compatibility and give us the potential to run Ruby as fast as Java or C. The entire Ruby world will change over the next year, and JRuby 9000 will be leading the way. We'll talk about what Ruby's going to look like once JRuby is "over 9000".

Write once run anywhere is both a blessing and a curse. For years, the WORA promise has ensured a consistent, compile-free experience for JVM users. Unfortunately, sometimes pure-Java libraries just can't do what developers need done. Sometimes, you just have to go full native. The Java Native Runtime is a core library and suite of support libraries for binding and calling out to native code. I'll show how JNR is designed, compare code and performance with alternative approaches, and talk about why the JDK needs a standard FFI (foreign function interface) in Java 9.

Write once run anywhere is both a blessing and a curse. For years, the WORA promise has ensured a consistent, compile-free experience for JVM users. Unfortunately, sometimes pure-Java libraries just can't do what developers need done. Sometimes, you just have to go full native. The Java Native Runtime is a core library and suite of support libraries for binding and calling out to native code. Without writing a line of C, you can make native calls, pass callbacks, and manage off-heap memory; every OS, library, and kernel-level feature is available to Java developers. I'll show how JNR is designed, compare code and performance with alternative approaches, and talk about why the JDK needs a standard FFI (foreign function interface) in Java 9.

A tale of sadness and a tale of joy: the tale of invokedynamic use in JRuby and a few other projects since the first prototypes dropped in 2008. I started experimenting with invokedynamic in JRuby in version 1.1.5, early in the JSR-292 process, and kept up with changes as they arrived. Today, JRuby utilizes invokedynamic for several aspects of the Ruby language, and we're finding more ways to use it every day. I'll talk about where we've been and where we're going...what works and what doesn't...and how to understand everything happening under the covers.