 So what do you crap nice to see all of you is my first time here very excited and I got a lot of stuff to cover So let's just jump right in here There's my basic information. I have been a Java JVM guy pretty much my whole career about 24 25 years now and Amazingly about 13 years now of working full-time on a Ruby implementation. It's been very exciting We are thrilled to have the sponsorship of red hat And as I mentioned the first time here, I'm gonna spend a few days here and then do some exploring in Chiang Mai and Very excited. All right mentioned red hat again. Thanks very much for sponsoring us We've all had some great sponsors over the years that have kept the project going. We started out at Sun Microsystems We were at Engine Yard for a while and now over six years that we've been at red hat and they're funding two of us to work full-time on J Ruby We're also excited to see what happens with IBM as far as we know red hat stays red hat But we're going to get the additional resources and help from IBM to make stuff really really shine. So looking forward to that too All right, so let's get into it here and talk a little bit about J Ruby. How many folks are familiar with J Ruby? Okay about a third of the room it's posed how many people have a J Ruby application or I've ever done a J Ruby application in production All right, great. It's still like like maybe a fifth or six of the room there All right, so for the folks that are not familiar with J Ruby It's just a Ruby implementation. That is our primary goal with it always is to be as much a drop-in Ruby replacement as possible Currently our current version is compatible with Ruby 2.5 We're looking to do either 2.6 or 2.7 for the next major J Ruby release If you find something that's not working. That's just Ruby code Don't assume it's your fault. Let us know. It's a very good chance that we've missed some weird edge case And we can fix it up and get a new release out real quick Pretty much any pure Ruby gems ought to work just fine We actually ship a very slightly modified version of C Ruby's pure pure Ruby standard library And most of the major C extensions and native libraries that are out there have J Ruby versions or an equivalent library That will work well but like I say we want to be a Ruby implementation first and Then after that also be a JVM language and give you all of the power and all of the the capabilities of the Java platform So what kind of things am I talking about? Well here I had to throw this in at the last minute Just in the past couple days. I saw this tweet from Michelle on Twitter And she has two kitties that are named Java and Ruby And they they play together and they have a lot of fun and somebody else replied and they thought oh hey So this is how I found it. It came up in my J Ruby search So if they have a kitten together, yeah, that would have to be have to be J Ruby And then she came back a couple days later and here it is Java and Ruby happy together That sums it up right there. I think That's the goal we want J Ruby to be Java and Ruby working together But still the the capabilities and the power of both sides All right, so there they are So what kind of benefits are we talking about JVM Java platform wise? Well having it be widely deployed is nice It's available on every platform. Of course you have the amazing native JIT Capabilities for performance GC is never a problem. There's so many garbage collectors out there that are really amazing on the guy on the JVM Concurrency platforms and all the support across many different platforms libraries tooling Right once run anywhere. We've got folks that deploy J Ruby on the most weird exotic platforms with zero modifications to their apps All the libraries work all the drivers work. It just runs pretty much everywhere that the JVM runs. I Mentioned concurrency. So this is my machine when I was running some benchmarks for this system I've got my my four or you know eight virtual cores And one J Ruby process will be able to light up all the cores use all the resources in the system You don't have to spin up many many different processes. You can get the best out of your CPU with just a single J Ruby instance This is an example of a tool called visual VM And it's actually using a plug-in on the right called visual GC Which is showing a live view of the JVM's garbage collector as each of the generations fills up with objects gets cleared out And the garbage goes away On the left just some basic metrics there show you what CPU usage looks like show you how many threads are running in the in the J Ruby instance and this is just one of Thousands of tools that are out there for monitoring profiling and managing JVM based applications This one happens to also be free as part of the open JDK project I mentioned that we've got lots of libraries out there. Of course, we've got over 150,000 unique different gems in the Ruby gems world you can add to that over 340,000 JVM libraries that are available that do just about everything you can imagine if there's a library that you can't find in the Ruby world, there's probably a JVM library out there that you can pull into J Ruby easily Some of those libraries are fun things Here's an example of a minecraft plug-in framework written in J Ruby The code on the left is all you need to modify how many chickens come out of an egg when you throw it The funny story behind this is that Tom tested this out and made this video Tom is my co-conspirator on the J Ruby project He tested this out in a world that he actually intended to keep building things in and creating new stuff But after creating several hundred thousand chickens in his experiments He essentially had to throw the whole world away Sending wolves in did not solve the problem. It just made it worse So but the great fun that you can have with stuff that's built on the JVM using Ruby So J Ruby really is Ruby plus the best parts of the JVM We try to hide the fact that we're running on top of the Java platform Hide some of the weird edges of the of the JVM and make it just feel like a Ruby that has so much more power A quick little roadmap on J Ruby as I mentioned the current J Ruby version is Ruby 2.5 compatible. That's 9.2.8 We have finished off the 9.1 line. That was our 2.3 compatible and we're likely going to skip over 2.6 We're kind of going every other major Ruby version here The reason behind this is that keeping up with compatibility is a lot of work It's usually best if we can just focus for a few months on compatibility And then the rest of the time we do user support performance optimization and so on So most likely we are going to wait until 2.7 is done at the end of this year And then next spring we'll come out with J Ruby 9.3 supporting Ruby 2.7 compatibility This is a great place where you can help as new Ruby features come out We're always looking for folks to help us implement them add them to J Ruby. So we keep up And it's fine if you want to use Ruby code We have a large part of J Ruby that's just written in Ruby if there's a new feature that you can implement in a few lines A Ruby code submit a pull request Maybe we optimize it later. Maybe it runs just as well as is written in Java So it doesn't have to be a Java based patch And we're always standing by to kind of help people out and get them bootstrapped on helping J Ruby All right, so as a user as a Ruby user, how would you get started with J Ruby? We do have a site with downloads and community information and chat links and whatnot So you can certainly just go download J Ruby from here Really the only prerequisite for getting J Ruby running is that you have some JDK installed My personal favorite distribution is adopt open JDK They provide builds across several different platforms several different configurations of JVM Currently recommend Java 8 because Java 9 plus has some some security and module stuff that'll warn a little bit on some J Ruby things It's harmless, but noisy. That's all that's really about it there So then install J Ruby like I say you can download the tar ball or zip You can use our windows installer if you're a Windows based developer But generally we recommend just go get RVM or whatever your favorite Ruby installer is tell it to install J Ruby They all know about it and you'll have J Ruby running on your system in no time Here's a quick example using RVM Wait, nope there. Okay, there we go. It doesn't show on my screen. It's creepy. Okay, so here we go I'm skipping gem sets here just to kind of speed the process This is a little bit older video J Ruby 9 2 4 and then we're up and going that's all there is to it It doesn't have to build J Ruby because it's JVM based as long as you've got a JDK It will just run and then that's it. You've got it working J Ruby implementation and you can start doing all of the stuff I show here today So let's take a look at running a J Ruby and IRB. Of course, it's a Java world. So we put a J on everything It's J IRB for us You can just run IRB as well. JRB is just a convenient shortcut Here I am calling into some Java libraries. This is the swing GUI toolkit that comes with open JDK So we create a frame. We create a button We add the button to the frame Set the size to what is something visible so we can see it and then we show the frame And now we've got a live frame that is a GUI that will work all across platforms on any platform where open JDK works And you've got a screen We can add some event handling to our button and then when we click it our Ruby code runs And you've just written a little GUI in a few lines of Ruby code There's also the whole Java FX framework, which is supported by JRuby kind of the newer GUI toolkit for building JVM based desktop apps Certainly beats trying to find the right GUI toolkit in the right libraries on each platform Just write it in Ruby install the JVM. You've got a desktop application Few notes on on gems and paths Sometimes the system installers for Ruby will try to share gem paths So keep an eye out for that. There are different versions of some libraries for JRuby So we want to kind of keep our gems separate from CRuby's and just to keep that confusion down And one thing to keep that always bites me a lot of projects and libraries use the dot Ruby version file to automatically switch to a specific Ruby version It often does that completely silently and suddenly you're back in CRuby and not running JRuby anymore So something to keep an eye out if you start playing around with JRuby on your own I mentioned that we're always available for help. We do have a mailing list We are on various chat services should be pretty easy to find us and then of course our our GitHub project in the JRuby organization All right, so let's talk a little bit about JRuby's architecture So we are what we would call a tiered architecture, which means we have many different layers of execution and optimization So our Ruby code comes in here on the left We parse and compile that into our internal Ruby instructions very similar to how Ruby how see Ruby has its own VM and its own bytecode Then we pass that off to our own interpreter written in Java That interpreter will run the code for a while and as it gets hotter and it sees that you're using certain methods more We pass that off to the JVM as JVM bytecode. All right, that's our own jit phase So we turn it into JVM bytecode and then the JVM basically repeats this same process It interprets the bytecode for a while does a quick optimization Runs it a little bit more It turns that into better native code and then this cycle will repeat So basically the longer you run your Ruby code on JRuby the faster it will get and it shows in some of these benchmarks I'll show a little bit about the high performance the peak performance And some of the warm up a warm up time you see So let's talk first about low-level performance. One of my main jobs on JRuby is optimization memory optimization performance optimization I wrote the jit and some of the the back-end optimization that feeds it into the JVM I end up looking at a lot of assembly code to see how this stuff performs and you get to benefit I look at assembly code so you don't have to Okay, I'm gonna show some micro benchmarks here to begin with Of course generally these are not useful things unless your business is generating Fibonacci sequences or something But they are interesting for us to kind of explore what the the the low-level aspects of performance in JRuby are They're fun to show off and improve. It's easier for us to isolate specific things For example Fibonacci or Mandelbrough or whatever will help us test numeric performance And it's also a quick way for us to try out new JVMs new jits new garbage collectors and see how they're doing on Ruby code So the first one again not a particularly useful benchmark, but it generates a fractal Good test of numeric algorithm performance. This is very heavy on floating-point math And heavily relies on the JVM to take this code and ideally turn it into the optimized fastest possible native code Here's our little benchmark. You can see mostly just numeric operations here Couple nested while loops and then at the end we get Mandelbrough fractal generated So let's see how this looks across a few different Ruby configurations here We have see Ruby 2.5 coming in about 3.6 seconds The JIT is still coming along. I would hope to see more numeric improvement on on benchmarks like this But for now it's kind of a mediocre mediocre improvement to this point Then we have J Ruby here with just a regular Execution not using invoke dynamic, which I'll talk about in a second And I'll skip this because that's that column was supposed to be later I mentioned invoke dynamic So this is kind of our next tier of optimizing J Ruby First we turn it into JVM bytecode and then we leverage the features of the JVM This was added in Java 7 about 10 years ago it's essentially JVM support for dynamic languages and of course this works very well for us We worked very closely with the JVM engineers to make sure it could optimize Ruby code well I mentioned Java 7 and we helped them out a lot with it This has been steadily performed improving over time the performance continues to get better The amount of time it takes to optimize gets lower and lower and it's been using less and less memory Currently, this is an opt-in that you do with J Ruby You can pass a flag that says turn on the invoke dynamic compilation Mostly because it impacts startup and warm up time a little bit if you want peak performance Definitely will get you there, but maybe for day-to-day development. You don't need to run with that So here let's take a look at what our invoke dynamic performance looks like again We have our C Ruby jit our J Ruby and then a big improvement better than twice as fast We see anywhere from two to five times performance improvement Turning on invoke dynamic depending on what kind of code you're running And now we're also very excited that there are a wide range of JVMs and JVM jit compilers out there Very recently IBM's open J9 a completely different JVM from open JDK has been open sourced We're starting to play around with that and also very exciting. There's a new jit called grawl Grawl is a jit compiler for the JVM that itself is written entirely in Java Which means that it's been able to evolve very quickly It's been able to incorporate much more advanced optimizations And we're really starting to see some crazy improvements on on Ruby code now Let's take a look and compare these again. Here is our C Ruby 2.6 jit performance as it was the regular J Ruby performance Where is the oh here we go? This is the one I want So here is the C Ruby jit J Ruby invoke dynamic There's our nice bump bump from it the indie performance and now the really exciting stuff new jit technology All we got to do is flip a switch on the JVM and BAM Ten times improvement over our best numbers This is now very very close to what it would be if you just wrote this code in Java directly rather than writing it in Ruby It's really exciting stuff I've taken a look at the assembly code and it's practically there. It's practically the same stuff all right so Moving on we also do a lot of work trying to optimize J Ruby in memory JVM applications are traditionally thought of is kind of big and yes, it's very easy to create too many objects It's very easy to let the GC just clean up your mess after you But we want to try and keep Ruby in J Ruby as compact and tight as possible So what are some things that we're looking at well Ruby instance variables are dynamic But usually we can predict what a given object is going to have We don't need to implement it like a hash table, which would be terribly inefficient if all objects were basically hashes Ruby arrays are also mutable, but typically you're using small arrays You're getting it filled with the information you want and then not making a lot of changes after that We can try to optimize that as well So the trick we're using right now is we look at your instance variables We look at how you're using your arrays and try to compact it down Turn those instance variables or those array elements into JVM fields Avoid having all this extra overhead for a growable array behind the scenes It's for those of you who know how C Ruby works This is very similar to storing a few instance variables or a few array elements in the actual header of the object Keeps it more compact local to the CPU cache And avoids that extra memory overhead Let's see how this looks Here's what you would see if you ran a J Ruby JVM memory profile And you can see we've got lots of different sizes of Ruby objects here We're detecting how many instance variables are actually needed at runtime and allocating an object That's exactly the right size rather than having it grow and change and have extra layers of abstraction And this leads to about a 33 percent memory reduction. This is we shipped just this past spring Actually, so bunch of applications now use considerably less memory when they deploy on J Ruby Similarly the array optimization here We are only doing specialization for one and two element arrays But it turns out in a simple array a simple rails active record benchmark that more than half of the arrays Allocated are one or two element arrays that never change size So just by doing this very simple optimization We've managed to cut half of those arrays down considerably and again, it's about a 33 percent memory reduction We don't have all of those X all of that extra array overhead. We don't have that extra abstraction So a lot of work that we're doing to try and get performance working Take a step back here and mention one caveat. I mentioned earlier the warm-up time the tiered execution Runtime optimizations do an excellent job of optimizing Ruby code We are really able to get seriously high performance compared to pretty much every other Ruby implementation right now But unfortunately startup time and warm-up time are impacted by this We continue to reduce this impact over time But I want to be honest with you and show you how to kind of get around some of this this startup time impact So what kind of what kind of startup time are we talking about? It's not great This is CRuby versus JRuby without passing any flags and you know five ten times slower for certain commands Depending on how many gems you have this this gap will go up And this can be a pain in a development environment to have this running Every time you run a command to have to take this performance hit So why is this is this something that we're doing wrong? Well, if you look at CRuby Most most of the code that runs when you boot up a Ruby application is written in C. It's already optimized down to native code In JRuby, that's pretty much the exact opposite almost everything that runs in JRuby is JVM byte code It needs to warm up it needs to go through that whole tiered execution the jit finally optimizes it But it's usually too late for startup time It means that we don't really get to our peak performance until five ten fifteen seconds into the application run Means the commands take a little bit longer to get going And in fact if we run these commands repeatedly in the same JVM We start to get down very close to CRuby's performance the JVM does optimize this stuff eventually But initially it ends up being a little slower than we like So probably the best way to get around this right now is a flag we have called dash dash dev that you can use in a development environment Generally exported in an instance in an environment variable, so it's picked up by all your JRuby processes And this basically disables our jit which adds a little bit of startup overhead It tunes the JVM jit to not work quite as hard at the beginning of execution Because it turns these things off make sure you don't try and benchmark against it But this will get you 30 40 sometimes 50 percent reduction in JRuby startup time So if you start using JRuby definitely remember dash dash dev flag for local development can save you a little bit of a headache there We are also looking at being able to compile JRuby ahead of time into native code As part of the growl project there is a way to take JVM applications Compile the whole thing down to native code and then they should start up much faster The truffle Ruby project another another JVM ish based Ruby implementation is using this currently To boost their startup performance We're hoping to take it a little bit beyond what they've got We want to try and compile JRuby and your Ruby code down to native native code At least we can do that for all of your gems for all of the standard library So JRuby and your code your libraries will start up much faster in the future. This is a work in progress Showing a little bit how this helps JRuby versus truffle Ruby. Here is our dash e1 Probably our best best time about 1.7 seconds passing the dash dash dev flag Truffle Ruby with their native compilation definitely gets a big boost here This is pretty much as fast as running with C Ruby But because they don't pre-compile any Ruby code They end up having significantly worse startup time for larger commands This is what we want to actually solve We want to get down to that 0.5 seconds for something like listing all of your gems or running Rails commands So we'll work with them and with the growl team to get this to happen in the future Okay, so let's talk a little bit about web applications performance wise how you make a move to JRuby So I've got some small and some large examples here my small examples. I'm using Sinatra and Rota Some very trivial little benchmarks that are part of this Ruby benchmarks project I Was inspired this morning to try and get the Hanami example to work, but it has some database dependencies I didn't wasn't able to work through the exact details of those But you should see similar performance improvement on something like Hanami to what you have with Sinatra and Rota here And then of course I will show rails and show some small apps versus some large applications So Sinatra and Rota very well supported on JRuby We have many production users that are using Sinatra for very large-scale applications Some years ago the company called the guilt group who does a lot of flash sales Huge amounts of users coming in within an hour or two of a new sale coming out They were pushing tens hundreds of thousands of requests through a JRuby Sinatra application We hear this kind of thing all the time really can scale up small services extremely well on JRuby The examples I have here are very simple. They don't have any database They're not hitting other services But it'll give you an idea of what the bare bones request processing can do in JRuby with all of our optimizations All right, so let's take a look. I am comparing CRuby and JRuby and truffle Ruby here across these two frameworks So here's Sinatra in CRuby getting about 12,000 requests per second JRuby makes a big difference here Almost four times improvement about three and a half times performance. There it is three and a half times performance improvement Just by switching to JRuby passing the invoke dynamic flag. You can turn the the performance level of a Sinatra app way up I did try some of these on truffle Ruby. I was hoping to show some some better results I think there's still some some work to be done. They're they're not quite up to CRuby performance yet on these benchmarks similarly with Rota we've got 14,000 for the almost 15,000 requests per second in CRuby a similar ratio 44,000 requests running this on JRuby exact same application Again truffle Ruby seemed to take a hit here So I started to wonder what might be wrong with the truffle Ruby results And one thing that it turns out I was running with Puma here Puma has a native extension and in order to support Native C extensions truffle Ruby has to have basically a global lock around them can't trust that C code can't trust that native memory So I thought I'd run this again and just run with a single thread And then as you'll see JRuby goes down we we take about about a We go down to about 25% so it's a four core system So that's not surprising truffle Ruby doesn't really go down at all So they're they're kind of bottlenecked on the C extensions and this is something that I'm sure they'll work on I wanted to show this side of it to demonstrate that there are reasons why this isn't quite there yet So I thought hey, let's use a web web framework web server implementation that doesn't use a native extension So I thought I'd throw a web brick at it. Why not if we could run web brick Well, then maybe we can see some similar numbers on the truffle Ruby side It turns out that JRuby actually runs this application with web Rick Faster than on Puma using a native HTTP parser and an optimized request loop and everything So we can run with just with our optimizations. We can beat Puma using web brick And as expected this did give a little bit of improvement to truffle Ruby So C extensions, you know, they're kind of a problem for Ruby these days I wish these guys all the best in the world best of luck in the world to try and support them But this is this will be an ongoing problem most likely Now I want to be honest again about our warm-up time performance So when I first start this after the first five seconds of cranking requests through it We do come in a little bit slower than C Ruby a lot of folks will run their early benchmarks Assume that JRuby is not going to be able to perform and then just give up on it But again as we run we optimize the JVM optimizes slowly our performance ends up climbing well well above C Ruby The same graph here wrote us a little bit simpler than Sinatra It doesn't have quite as much reflective magic internally So our numbers are pretty much the same as C Ruby and then it just keeps going up from there All right, so let's move on from small frameworks to something a little bit more substantial here So JRuby on Rails also can really benefit from the JVM from the libraries the garbage collector the JIT And the best part about this is one JRuby on Rails process can handle your entire site It doesn't matter how much hardware you want to throw at it. We will make use of it We will handle hundreds thousands of requests from users at the same time Are there users of JRuby in rail rails in production? Well, I just heard about one today That's deploying JRuby on rails as a packaged application for companies here in Thailand We hear this all the time JRuby is out there JRuby scaling some really large applications It's stable and it works really well And we've been thrilled to have all these great users tell us these stories And we believe that this is the best way to scale rails applications today All you have to do is start up one JRuby instance and your scaling is done. You're good to go So how do we start making this move? What's what's the differences here with JRuby on rails? Well, the configuration differences are pretty minimal Swap some gems around and if you generate a new rails application Rails will generate all of these these changes for you ahead of time We have a minor change to database YAML here We have a driver that works exactly the same as the rails drivers do so make a couple tweaks and you're good to go Are threads within our process so rather than using workers spin up multiple threads and handle all of the requests with one process Here's some Some of our test results on rails six Three nines passing is pretty good The kind of stuff that isn't passing is things like this if you really have a need for Nanosecond accuracy on your date times You know we talked to us We'll see if we can help accommodate you But these just kind of make us sad the probably just issues that we need to fix in the test framework So rails really is the thing this is this is what tests the completeness the performance the maturity of a Ruby implementation If you can't run rails fast, you've got work to do This is still by far the biggest use case for Ruby web development in general and rails specifically and over the years It has been very frustrating to optimize this J rubies run little micro benchmarks and small applications faster than see Ruby for years for almost a decade now But rails only recently have we managed to finally crack that nut and get the performance. We're looking for So times are changing. Let's take a look at some of this So first of all active record most rails applications pretty much live and die by the performance of active record This is where most of your overhead is going to go This is where most objects created in the system usually are coming from And this is where we've spent a lot of time trying to optimize make sure that active record is fast Hopefully the rest of rails will come along with it I'm doing some create and read and update measurements here and just comparing see Ruby 2.5 versus J Ruby on a JDK 11 We'll jump right into the numbers here Generally about 30% performance improvement on all of the the active record benchmarks here So this is lower is better trying trying to run a thousand select queries with various data types We're trying to test and make sure they all serialize across the wire properly This this pretty much carries over to the create and update as well Our performance is usually going to be 20 to 30 performance 20 to 30 percent faster 20 to 30 percent less overhead than running the same thing in see Ruby So now what about scaling rails itself? Well, this is kind of the classic problem on see Ruby We don't have concurrent threads. We can't actually use multiple cores at the same time So we need to spin up separate processes And there's lots of tricks like copy-on-write and the new compacting garbage collection that try to reduce the overhead of having these Different processes, but these processes invariably will grow on their own they will have in-memory data sets that they need to maintain and You're also running Multiple implementations of a garbage collector multiple implementations of your database drivers. This is wasting resources across implementations Of course, we believe that J-Ruby's the answer for this a single Multi-threaded process can run the entire site. You've got one garbage collector. You've got one set of jits It's all sharing the optimizations and it runs and takes care of all of your requests at the same time So I have one benchmark. That's just a simple rails performance bench. This is a generated blog post application This one I were actually running on a real instance in EC2 extra large C4 Through plenty of memory at it gave it some warm-up time and you know a little less scientific I am running the database the benchmark and the application all in the same instance. I don't think for this benchmark It makes a whole lot of difference Let's see what we get for a quick request per second on this simple blog post app here We have C-Ruby running about a little under a thousand requests per second J-Ruby getting again 20 to 30 percent performance improvement just in the throughput of full stack Rails requests and this would really without any change to the application just switch over to J-Ruby started up You can get a performance improvement Again trying to be honest here about what warm-up time you might see Sometimes folks will deploy a J-Ruby application into production and then have a script that might run through a few of the common Operations get the rails code booted get the application Warmed up a little bit and then then you'll get that that performance boost that you need for Depending on the size of the application this warm-up curve can get a little bit longer We are working on various ways to shorten that try to get to peak performance much quicker So I've mentioned making better uses of resources here J-Ruby on rails will generally use less memory for any large-scale Ruby application an Individual J-Ruby will be bigger than C-Ruby for sure But once you pass two or three or four C-Ruby instances Usually we start to come out ahead and then of course you can you can take that all the way to a hundred concurrent users You'd need a hundred concurrent processes to run in C-Ruby and of course a single J-Ruby process will be way ahead on memory use The second benchmark I want to show is a ruby gems org We actually can run ruby gems org. It's largely functional. We're still working on some edge cases here This is just running on on a machine like this here an i7 16 gig of memory Again running everything on the same system, but a generally good example of what kind of performance we can get on a large application So let's take a look here We've got our the blue is J-Ruby running with Puma a single process using all the cores goes way up and get in and stays up above at the top Compared to C-Ruby running in this case. I think it was the 10 or 20 processes Using significantly more memory than J-Ruby. It does get up to a point where it performs pretty well Certainly compared to a single ruby instance But we did start to see some errors cropping up at higher levels of concurrency more users coming in J-Ruby was able to scale well beyond this without any errors We these are the memory numbers that we saw so C-Ruby with 20 workers versus J-Ruby with 20 threads This is basically how much memory it was consuming on our system I know that the gem Alex stuff should help the compacting GCs should help the copy on right is Sometimes helping this but usually J-Ruby will use less memory for any significant application So some takeaways for the scaling here generally uses less memory More memory stable over time once we get to that peak level It stays pretty much solid and after a little while won't continue to grow We did see the C-Ruby processes continue to use more and more memory over time Certainly more CPU efficient. We are getting the best use out of the processor With the downside that we have a little bit more warm-up time So I think it's safe to say that J-Ruby is definitely the fastest way to run rails applications We're hoping that more folks will give it a try And I'm gonna have to kind of speed through this part. We started a little late So I think I can push it a little bit. Maybe All right, so migrating to J-Ruby. Well, so try it out New applications will be the easiest obviously Existing applications will require a few extra steps tweaking some configurations Bundling installing and dealing with C extensions and then running your tests So the use case I'll go through very quickly here is discourse This is a very large rails application over 500 gems 250,000 lines of Ruby code significant application It's not currently supported, but it does almost work It works enough that we were able to get the main page to come up So step one here. We have a tool called J-Ruby lint Just a linter like a rubocop sort of thing Gem install J-Ruby lint you run JR lint and for discourse and application this large It had a few things to say about it Lots of little hints and tips warnings about concurrency First of all, what you'll see is it will try to find any unsupported libraries and supported extensions These list of extensions and the alternatives that you can use actually comes from a JRuby Wiki page that you can go update Provide the name of a C extension the name of a JRuby equivalent Everybody else then will run JR lint and see that alternative. So help us help us fill this list out And here you can see the the name of the CRuby gem and the suggestions for how to replace it There are as I mentioned also threading concerns doing or equals or plus equals are not guaranteed to be atomic They might have different results if you have many threads We will flag those and show you different ways that you can fix those threading problems We'll also mention some unsupported or poorly supported features like object space forking And tell you what you need to do to get around those In the case of fork generally, it's using the the multi-process model of MRI probably won't have to deal with it too much on JRuby The next step is replace those C extensions Why don't we support C extensions? Well, they're often used for performance reasons, which of course we don't have as many performance issues The API is enormous. It's really huge and there's a lot of difficult things to do Direct pointer access to see Ruby objects is one of the biggest problems And we did actually try to support this years ago But it turned out our implementation to support as much as possible to run C extensions was slower than just writing it in Ruby So we drop that we recommend different ways to get around this So we run our bundle install. We see there's some C extensions Here's the options. We're gonna run through we can remove it if you don't need it You can use a pure Ruby version if the performance is okay You can use a native library and just call into it using FFI I won't go into details of that, but there's plenty of talks about FFI You can call a Java library just like I showed at the beginning or you can also write a JRuby C extension The last example I want to show here is the OJ library So this is an optimized JSON library for parsing and dumping JSON data No support for JRuby currently, but it's coming along And it's it's a common dependency of discourse and many other libraries So it's something that we kind of have to support and Tom has been working on this OJ for JRuby is about 9,000 lines of Java code compared to 20,000 lines in the C in extension Most of the tests run minor things that we've just got to work through the edges here And it actually performs much better than the C extension Here is our load performance across the implementations. That's C Ruby for a couple different sizes of data JRuby and JRuby with OJ running significantly faster getting the best out of the JVM Similarly on the dump performance JRuby looking great And that's it once you have that working once you bundle install you should be ready to go and deploy your application So wrapping up now JRuby is here for you. We we Love our users. We're always online We want to talk to you and see what we can do to help you get more out of Ruby We want to help you get the best of the JVM without leaving the Ruby platform Getting the best out of the jit and garbage collection and deployment All of these JVM libraries all of these languages if you want to start playing with Scala or Kotlin or closure We have plenty of hybrid apps out there that use those together with Ruby code to scale up your applications save money on all the server resources you're using to run them and Let's keep the the Ruby dream alive. Thank you very much. All right. Thanks so much I think we have a few minutes for a couple of questions from the audience. So The first one is you mentioned discourse Maybe you could talk about what are some other Large or well-known production applications or companies using JRuby Sure, let's let's see I know that for example SoundCloud runs a significant portion of their stuff on JRuby A favorite of mine the BBC news Website all of the election results that are displayed you can imagine the kind of overhead that they would have displaying election results That's actually a JRuby application. It's not rails. They've built their own custom little micro service setup But all of those results are served as a JRuby application One of the more fun ones is the the Allen telescope array It's a radio telescope array out in California. It's used as part of the SETI project to search for extraterrestrial intelligence last I heard JRuby is actually used to coordinate all of the different telescopes Of course, they've got some C++ or assembly. That's actually moving these things around gathering all of the data But they use a JRuby console to search for aliens. I think that's pretty awesome Great one more question As far as teams migrating from C ruby over to JRuby, what are the common problems that you that they tend to run into startup time That's pretty much like the the major thing We we understand that this is a problem. It's a problem for us, too We we have we use JRuby every day all day and we have to work around this As I mentioned, we are working on various ways to improve this That dash dash dev flag continues to get a little bit better every over every release The JVM itself starts to get a little bit better over every release So we are getting there. It is it is improving over time. The next thing people run into would be C extensions libraries that don't have a JRuby equivalent Most of the time there's a JVM library that's out there like nine times out of ten. You can just pull in a JVM library Wrap let a little write a little wrapper code around it and your applications up and going again in the rare cases where you do need to write it in a JVM native language You could use Scala or Kotlin or closure if you don't want to use Java There's no reason you have to be tied into that one language. So that usually helps mitigate the problem pretty well All right. All right. Thanks very much. Yeah