00:00:00.000
ready for takeoff
00:00:16.940
all right we're gonna get started I got a lot of stuff to get through uh I am Charles Nutter I am going to be speaking
00:00:24.000
about the project I've worked on for the past 16 years jruby uh give you a little
00:00:29.340
idea of what it is why it's useful and how you might get started using it first of all I want to thank yarden
00:00:37.140
leifenfeld who could not be here she actually was going to do a jruby talk in this slot uh but she could not make it
00:00:43.860
she had some other uh other commitments but check it out it's uh there's videos of it online Ruby and jvm a love story a
00:00:51.539
lot of in-depth exploration into how her company's been using jruby uh building a
00:00:57.239
debugger based on the jvm debugger uh lots of cool stuff so so check that out
00:01:02.760
um apologies to yard and I was not able to include any of her content because 30 minutes is not long uh also thank you to
00:01:10.500
Red Hat IBM I am a red hat employee they have sponsored us for over 10 years now
00:01:15.720
to work on jruby and yep that's what we do full time we work on jruby um don't
00:01:21.600
ask why uh they they're very generous with open source projects so buy red hat
00:01:27.780
um uh and of course cheers to Tom Annabelle uh who is uh still uh isolating at home uh worried about uh
00:01:34.619
kovid and such uh he's we've been co-leading Jay Ruby for these past uh 16
00:01:39.659
years and uh we've done a lot of traveling and a lot of beer drinking over the years so so check it out he is
00:01:45.960
the the uh the silent partner that does all of the real work on Jay Ruby behind the scenes
00:01:51.720
all right let's get into it jruby so what is jruby well it's it's not
00:01:57.060
surprising uh a ruby on top of the jvm how many folks here are somewhat familiar with jruby
00:02:03.840
okay how many folks have uh actually run something on jruby
00:02:09.000
pretty much the same people okay so it is a ruby implementation we focus very heavily on making it a ruby
00:02:15.420
implementation first uh and a jvm language second there are a lot of folks in the Java side that love to use jruby
00:02:21.480
to script Java applications but we primarily focus on the Ruby developer experience once you install jruby you
00:02:28.140
run out of the command line all the same commands are there we of course get all the benefits from being on the jvm that
00:02:33.660
I'll I'll go through a little bit later but the general idea is that Ruby code should just work uh you should be able
00:02:39.420
to take any pure Ruby application and many of the extensions that are out there that have jruby versions plug your
00:02:45.360
application into jruby and it should run it should just work out of the box uh we don't have the C extension API that c
00:02:52.260
Ruby does we have our own extension API so some libraries sometimes need to be ported we don't support forking because
00:02:58.560
the jvm doesn't support forking and different from C Ruby our threads actually run in parallel so one process
00:03:04.680
will saturate your entire CPU you don't need to run multiple workers
00:03:09.720
uh I've been using this slide for years uh some of these companies no longer use jruby but all of them did at one point
00:03:16.500
uh some fun ones on here like uh the BBC they use a j used or maybe still use a
00:03:24.239
jruby based application to deliver all of uh the election results so for example the last Scottish referendum on
00:03:30.659
Independence uh that was all delivered the results through a jruby based application uh I'm not sure NASA's on
00:03:37.920
here um I'm not sure if they're in charge of the uh Allen telescope array but jruby
00:03:44.099
was was once used there to uh script all of the components for one of the seti
00:03:49.680
projects searching for extraterrestrial life fun stuff there I also know that we are still in use as the refueling
00:03:57.480
terminal for oslo's gardamon airport that's kind of a terrifying one
00:04:03.540
um but exciting so like I say it's a ruby implementation uh so let's talk about Ruby
00:04:09.900
compatibility uh just last week we finally managed to get Ruby jruby 9.4 out uh that jumped from our Ruby 2.6
00:04:17.760
level of compatibility all the way up to Ruby 3.1 and pretty much all of the
00:04:23.160
features in those versions have been implemented and released uh notable exceptions we don't support the fiber i
00:04:29.880
o scheduling API yet and we don't support reactors but I don't know if many people are using those yet anyway
00:04:35.820
uh we just do have jruby 9.3 probably going to maintain that for the next year or so it's kind of demand driven so if
00:04:42.540
people continue to use it and continue to have 9.3 apps in production we will keep putting out uh security and fixed
00:04:48.419
releases uh we always focus on compatibility before performance so jrb
00:04:53.639
9.4 has had almost no tuning no performance optimization during the time we worked on it it still runs very well
00:05:00.479
as I'll show you later but expect to see big improvements now that we're caught back up on compatibility again
00:05:08.040
so why is Ruby on the jvm interesting well of course the jvm is is everywhere every platform that's out there has a
00:05:14.580
jvm for it uh and most of those are very well supported by either Oracle red hat
00:05:21.000
or any of the many companies that do jvm support uh we get for free excellent jit
00:05:26.880
compilers various different versions of jit compilers multiple garbage collectors with all sorts of tuning
00:05:32.280
options uh we get great concurrency out of the box the runtime itself is made to run highly concurrent and then of course
00:05:39.120
many platforms we also can access all of the libraries that are available on the jvm whether they're written in Java
00:05:45.180
Scala closure whatever you can just import those into your Ruby code and call them as if they were a regular Ruby
00:05:51.300
application Ruby Library uh lots of tooling it's one of the things that jvm's known
00:05:56.699
for monitoring tooling uh production monitoring debugging uh profiling options all of that stuff also works
00:06:03.900
pretty much out of the box with jruby and of course because we're running on top of the jvm you can run your Ruby
00:06:09.539
application on lots of different and unusual exotic platforms um we were one of the first uh
00:06:15.240
alternative Ruby implementations to have support for Apple's M1 we run on weird platforms like OS
00:06:22.280
as400 uh we run on AIX so if you have any weird old application servers out
00:06:29.220
there that you want to start moving to Ruby you can do that too uh so this is an example of one of the
00:06:35.220
tools that we've showed for years this is visual VM and on the right side here it's running the visual GC plug-in which
00:06:42.900
is showing the live view of what the garbage collector heaps look like so you can see that the generations fill up
00:06:49.560
objects get promoted uh then it's cleaned up again but you get all this with jruby and you can hook up to your
00:06:55.860
Ruby application in production many cases and do this monitoring for for no
00:07:01.020
cost of course I mentioned parallel uh as we'll see later jruby can do very well
00:07:07.740
utilizing all the cores in your system so you don't have to worry about trying to manage multiple workers and trying to
00:07:13.860
scale that up dealing with the extra memory usage one process with many threads will take care of your entire
00:07:19.919
system and then since we can integrate with Java there's a lot of fun stuff we can
00:07:25.199
do like the progen uh framework which is a bucket based I think bucket-based
00:07:31.740
plug-in for using Ruby to write Minecraft mods and here this is just
00:07:37.080
basically modifying the number of chickens that come out of an egg when you throw it uh Tom Moore did pretty
00:07:43.500
much all the work on this and I think he ended up destroying a world by creating too many chickens when he was playing
00:07:48.960
around with it so getting started with jruby uh you can check out jrb.org there's
00:07:55.199
lots of information there generally the process is just you have to have a Java
00:08:00.720
jdk of some kind installed on your system which is pretty much standard for for all the linuxes it's easy to install
00:08:06.599
for Windows and Mac OS uh we recommend Java 11 or higher we work on all
00:08:13.620
versions of java from eight and higher probably going to be dropping Java 8 and
00:08:19.020
possibly 11 for our next major release but for the 9.4 cycle wheel continue to
00:08:24.539
support Java 8. uh and then install jruby usually the best way to do that is to use your Ruby installer like rvm or
00:08:31.500
or CH Ruby or whatever uh you can pull down a tarball if you want or a zip file we
00:08:38.159
have a Windows installer there's a Docker image out there that we maintain lots of different ways to get it but the
00:08:43.440
only real requirement is having a jdk somewhere on your system and then give it a shot so here is using
00:08:49.320
rvm and I switched to jruby uh and then this is an example of calling right into
00:08:54.360
some of the Java core libraries so Java Lang runtime we get an instance of that
00:09:00.180
we can see the available processors we can see the free memory any jvm Library that's out there like this can be just
00:09:07.500
be pulled in and called as if it was a Ruby Ruby uh Ruby object Ruby class
00:09:13.260
all right so probably the biggest uh use case for uh Ruby folks on jruby is jruby
00:09:19.140
on Rails and this does absolutely work it works very well there are lots of jruby on Rails applications in
00:09:26.040
production uh it's hard to know how many but there's hundreds maybe thousands of people out there that run their
00:09:31.860
applications on jruby uh you get the benefits of the jvm just like you would with any other Ruby or any other jvm
00:09:38.100
application uh and I still believe that this is the best way to scale large applications large Ruby applications
00:09:45.180
right now you can take if you can get it to run on jruby make sure your tests look good make sure your performance
00:09:50.580
looks good you will be able to take one jruby instance and run your entire system run your entire site
00:09:57.300
uh configuration differences if you're migrating an existing application are usually pretty small uh there are a few
00:10:04.560
gems that we don't support uh the if you're using the Ruby uh the mini racer
00:10:09.839
which is based on V8 we have a different JavaScript implementation based on either Rhino or Nas horn that you can
00:10:16.019
use uh the database changes
00:10:21.720
um oops go back here yeah
00:10:26.940
slow animations database changes so if you're running on
00:10:32.399
MySQL we don't support the Unix sockets so you'd want to put in a host and port
00:10:38.880
and then the configurations for how many threads and workers of course we're going to use only threads so bump your
00:10:45.300
threads way up and you don't need to run multiple processes so turn off the worker stuff
00:10:51.360
and I'm happy to announce that rail 7 also is working well on jruby I'll be
00:10:56.760
using that for some of the benchmarks later on the main thing that has to be updated when we support a new version of
00:11:03.000
rails is incorporating all of the changes to active record that have happened sqlite is doing very well
00:11:09.680
MySQL is working but needs a little bit more help there and postgres we're just
00:11:15.000
starting to get into but in the next couple weeks we will have all of those three databases updated and then
00:11:20.700
hopefully be able to expand and have Microsoft SQL server and others working as well
00:11:26.459
uh so this is test runs of everything except active record on rail 7 and
00:11:31.800
largely everything pretty much Works um if something happens in your application doesn't appear to be
00:11:36.959
behaving like it would on the C implementation the standard implementation of Ruby just file a bug
00:11:42.240
don't don't think that it's your problem it could be us and we will very quickly fix it and we'll be doing a bunch of
00:11:48.420
update releases for jruby over the next few weeks a lot of these failures are also uh kind
00:11:54.720
of silly ones like you know the rounding is a little bit different on the jvm
00:11:59.880
sometimes or printf formatting is a little bit different in our implementation so most of the failures
00:12:06.180
that you saw there are not particularly important but again if you run into something that affects your application
00:12:11.279
let us know we don't like those but we're getting there okay so our active record adapter is
00:12:18.720
called active record jdbc adapter uh we do a sort of version matching uh so the
00:12:25.200
six dot whatever rails uh is supported by our 60.0 active record jdbc adapter
00:12:32.040
and then of course seven will be 70.0 I believe the sqlite and MySQL uh 70.0
00:12:40.019
adapters have been released as of this morning so you should be able to generate an application and get up and
00:12:46.440
running pretty quickly and as I mentioned postgres needs a little bit more work uh here's the SQL Lite test
00:12:52.860
results looking pretty good but as I say we've got a few more things to work on
00:12:57.959
so let's talk a little bit about performance um it's probably the key reason why you would want to try jruby
00:13:03.000
on Rails uh so when you talk about performance you have to kind of consider what is it that's important to you uh if you're
00:13:09.959
doing a lot of straight line heavy data processing maybe that's what you want just straight line performance do you
00:13:17.459
want High concurrency do you want to be able to handle a lot of users without spinning up a lot more instances uh is
00:13:23.399
is it a command line application if it's a startup time issue maybe jruby's not going to be the best choice for that we
00:13:28.920
have C Ruby has been optimized for startup for many years so it's difficult for us to compete with that but we
00:13:35.579
continue to improve warm-up time do you want an application that is at its Peak Performance
00:13:41.459
immediately or is it okay if there's a little bit of warm-up that's required to get up to uh full speed how about the
00:13:47.760
memory size is it an issue of consuming too many too much memory with too many workers uh maybe you only have one
00:13:53.880
instance then C Ruby might be the better choice for you but you've got to consider all of these things when you
00:13:59.639
talk about performance and Ruby implementations because if you're optimizing for only one of these and you pick your implementation based only on
00:14:06.660
uh startup time or straight line performance you'll be missing out on some of the other pieces and it probably
00:14:11.760
won't help your application out uh so some notes on benchmarks as well benchmarks are very situational very
00:14:18.959
specific um what looks really good in a micro Benchmark may not look so good in a
00:14:24.120
production application uh you may have great straight line performance and then under concurrency things start to fall
00:14:30.120
apart uh you may look good in a single instance but then when you try to scale
00:14:35.459
it up to many users uh things get too big in memory and start performing badly so it's really important that you
00:14:41.820
Benchmark things that are important to you and to your application rather than trust what I say or what other
00:14:47.699
implementers say about their own implementations so for this uh for this talk I'm going
00:14:53.160
to do three little example benchmarks uh rails bench which is a kind of a canned
00:14:59.160
contrived Benchmark mostly for measuring the overhead of the Rails framework itself
00:15:04.920
um it doesn't use any cert it doesn't use any web server it doesn't make socket connections it's just a single
00:15:10.019
SQL light plot blog application run in a single script in a single process as
00:15:15.720
fast as possible useful for figuring out what's in your what's the the slow parts of the Rails framework but maybe not so
00:15:22.079
representative of an end-to-end application which is why I also will do an end-to-end Benchmark of another small
00:15:28.980
blog application running on MySQL and then a couple notes on just active record performance and about where we
00:15:35.160
stand compared to C Ruby all right so I mentioned railsbench uh simple blog app uh the simple scaffolded
00:15:42.899
generated app uh using a sqlite database it's all just single thread cranking
00:15:48.300
through requests as fast as possible and you know not great for measuring a real
00:15:53.699
world application but perhaps gives you a good idea of slow points within rails itself
00:16:00.480
here's what we'll be running today uh I have 312 both with and without the wide
00:16:06.300
jit compiler I'm running truffle Ruby 22.2 I believe the current is 22.3 so
00:16:12.180
there may be improvements there um but uh you know like I say give these
00:16:17.699
things a try yourself run your own applications on them and you'll figure out what's working for you and then of course the latest jruby 9.4 running on
00:16:25.079
Java 17 which is the current long-term support release of the jvm
00:16:31.860
all right so this is the rails bench results that I was able to get on my system uh very impressed that yjit is
00:16:40.079
helping quite a bit here uh it's been a slow process getting good jits into C Ruby uh but yjit is is doing pretty well
00:16:47.339
uh I know that the Truffle Ruby numbers are supposed to be a little better than this uh this is what it ran as on my
00:16:54.060
system so again benchmarks can kind of trick you uh if you're not paying
00:16:59.160
attention uh maybe this will be better if you run it yourself go ahead and give it a shot and then jruby pretty much
00:17:04.980
comfortably faster than uh ygit here again this is with very little performance work over the last year or
00:17:11.579
two we're hoping to improve this quite a bit more so what does a benchmark like this give
00:17:17.160
us well we it tells us our straight line performance that's about it we're not
00:17:22.380
really getting to see what concurrency looks like we're not getting to see what startup and warm-up time look like and we're not getting to see how what what
00:17:28.500
the effect of these runtimes is on the memory size of the application so let's
00:17:33.600
talk a little bit about those so memory footprint this is a challenge for those of us on uh the jvm and modern
00:17:42.059
runtimes like that more complex run times take more memory the jits have to
00:17:47.220
run they have to keep multiple copies of code in memory the garbage collection strategies may use more memory out of
00:17:53.280
the box uh difference GC strategies may change the way that it uses memory and
00:17:59.220
we're comparing with C Ruby which has been optimized for years mostly based on Startup time and memory there's been
00:18:06.240
there's been work on straight line performance too but it's it's tough for us to compete in the startup time area or in this overall size of the process
00:18:13.200
so if we're not looking at those numbers as well as straight line performance we're not getting the whole story
00:18:19.320
so the memory footprint on this is one where we are penalized quite a bit by our runtimes so this is again just the
00:18:26.760
single threaded straight line performance of the Rails bench see rubies Rubble to run at about 80 to 90
00:18:33.660
megabytes or so on my system uh jruby and truffle Ruby using a bit more now
00:18:40.200
these numbers can be tuned uh the jvm tries to use a lot of memory to give its
00:18:45.900
garbage collector room to breathe you can choke that down a bit and for example this Benchmark could probably
00:18:52.320
run with a 200 megabyte Heap or run in a 300 megabyte jruby process if you tuned
00:18:58.559
it a little bit and I assume that there's something you could do with truffle Ruby to reduce this as well
00:19:04.140
so warm-up time uh again trying to be honest about some of these performance results you can get things running
00:19:09.539
faster on these implementations but there are other penalties uh in a
00:19:15.299
runtime like jruby basically everything starts out interpreted uh not even just jruby itself but the Java string
00:19:22.679
implementation the Java list implementations all of this starts cold and it all has to jit and warm up so
00:19:29.580
that lengthens the amount of time it takes to get to full speed performance uh the GC also will be adjusting Heap
00:19:37.380
sizes and changing strategies as your application runs it may take a while for it to get to that sweet spot where it's
00:19:44.100
using a minimum amount of CPU to run we know that these are issues we're always
00:19:49.200
trying to improve our warm-up time we're always trying to reduce our memory footprint and really you can help by
00:19:55.320
letting us know whether your application is seems to be taking too much memory or if it never seems to get up to speed but
00:20:02.160
we continue to improve this all the time so let's take a look at warm up as a second hand second piece of this here uh
00:20:09.900
see Ruby with ygit it it doesn't prove over time but it gets gets up to speed pretty quickly uh along the bottom this
00:20:17.039
is iterations of the Rails bench Benchmark it Loops multiple times uh
00:20:22.380
doing 2 000 requests each time uh and so on my run by about the 10th iteration uh
00:20:30.120
C Ruby was pretty much up to the full speed that it was going to have and stabilized uh jruby uh only takes about
00:20:36.900
six of those iterations to get to a stable performance level but you have to consider this you put an application in
00:20:43.559
production with jruby those first you know uh 60 to 120 000 requests May
00:20:50.820
slowly increase in performance the early ones may be a little bit slower uh some people will use a script to warm up
00:20:57.240
their application after they deploy it to production um and some some folks don't care too much about this their applications run
00:21:03.240
pretty quickly get lots of requests and warm up pretty fast if we overlay these we can see jruby basically passes C Ruby
00:21:11.039
with yjit about the sixth iteration of this benchmark and then similarly truffle Ruby uh it
00:21:17.400
takes a while to to get up to its stable performance it's actually much longer than this uh on my system it took about
00:21:24.780
70 iterations of these 2000 requests for the performance to finally stabilize and
00:21:30.419
it eventually does get there and it it should be fast and should run your application well but again it's
00:21:36.240
something you have to consider when you're running with these optimizing runtimes
00:21:41.400
so really benchmarks lie and all of the stuff here you should take with a grain of salt you should try your own
00:21:47.340
applications try your own uh Troublesome scripts that you're you're trying to get performance out of and make sure that it
00:21:53.940
works on your code run your application on these runtimes and then you'll get a better idea of what it's going to do for
00:22:00.179
you in production so let's take a look at a more realistic Benchmark an end-to-end or rails
00:22:05.580
application so this is again just a simple scaffolded blog application but running on MySQL so it's a little bit
00:22:11.640
more real world um I'm just running I was running it on my local i7 Linux machine uh here we
00:22:18.120
have C ruby31 with 16 workers and two threads each which was about right to
00:22:23.700
saturate the CPU and then jruby and truffle Ruby running with 32 threads each in a single process but I had some
00:22:30.179
issues with truffle Ruby so I'll only cover that very briefly uh everything's local so that's a caveat
00:22:37.440
here I'm not running a database server on a separate machine I'm running Siege to drive the the web interface
00:22:44.400
um so there's there's overhead from lots of things on the system um mysql's in a Docker container so there's
00:22:51.360
going to be a little bit of overhead compared to running it natively on another machine and it is a very simple
00:22:56.820
application so I just ran siege for 10 second intervals gathered the requests
00:23:02.700
per second and then once things started to stabilize I I knew I was there okay
00:23:09.240
so let's take a look at the performance here on the blog application uh 20 or 2
00:23:14.820
000 requests per second is about typical for C Ruby 3.1 uh ygit does better here
00:23:20.820
so higher is better on this graph and gets about 23.61. again I'm very excited
00:23:25.919
to see that there is now a jit that comes with C Ruby that can give you a little bit of a boost and I know this is
00:23:31.440
going to continue to improve and this is where I ran into some trouble when I try to run heavily concurrent uh blog app
00:23:40.020
and just hit it with 1632 threads all doing requests it seems to choke on this
00:23:45.659
and it only uses about one cpu's worth of performance so I have a pending bug report that I'll file for the Truffle
00:23:51.840
Ruby folks and I won't really be discussing truffle Ruby more in this benchmark and then there's jruby which is
00:23:58.320
Comfortably twice as fast as C Ruby with yjit again it's a very simple Benchmark a very simple application so you should
00:24:05.700
try your own stuff now being honest again we have our uh
00:24:10.799
memory footprints so this was 16 inches of C Ruby and I'm just running with Puma
00:24:16.620
so there's minimal pre-forking minimal cow copy on right optimization here
00:24:21.900
about 1500 megabytes about 1.5 gigabytes on my system
00:24:27.179
um truffle Ruby despite the single threadedness of the performance I was still using about six gigabytes and
00:24:33.480
again I know that can be tuned down a bit um and 1400 megabytes for jruby so we've
00:24:38.820
kind of passed that point where jruby will actually be using less memory than C Ruby because it's a single process and
00:24:45.179
now actually this can get better I was able to run the same Benchmark and forcing the jvm to only use a 300
00:24:51.240
megabyte Heap which then with the rest of the jvm brings it down to 950 Meg now
00:24:57.179
we're actually starting to save money in production by not requiring as much memory for all of our concurrent users
00:25:03.360
and really you can throw as many threads as you want up to the limits of the machine and still keep within this 950
00:25:09.960
mag uh warm-up time kind of similar to The Rails bench takes a little while for
00:25:16.320
jruby to get up and going but once it gets there it's it's pretty good and it's fast enough on this Benchmark that
00:25:22.080
that curve goes pretty quickly we pass up ygit pretty fast uh so even if there
00:25:28.200
is a bit of slow requests at the beginning you will get up to Performance pretty pretty fast
00:25:33.539
all right final area uh talking a little bit more low level within activerecord we continue to improve our active record
00:25:40.500
performance over the years and this has been a really tough nut to crack active records very complicated uh but as our
00:25:47.400
adapter has improved as jruby has improved and as active record itself has
00:25:52.500
reduced the amount of overhead uh We've started to catch up a lot and again
00:25:57.779
thanks in part to the jvm improvements just going from java 11 to Java 17 has
00:26:03.000
given us like a 30 performance Improvement on a lot of benchmarks so we get a lot for free just by being on the
00:26:08.820
jvm all right so select performance uh these are the numbers that I got with C Ruby
00:26:15.360
3.1 and then jruby again close to two and close to two times as
00:26:21.120
fast on a simple select so I'm doing a select Benchmark then also an update
00:26:26.700
Benchmark since they're probably going to be the things you were doing mostly most in your applications uh here's C
00:26:32.820
Ruby uh here the performance is even better uh easily two times two and a
00:26:38.159
half times-ish compared to C Ruby 3.1 so this is the kind of stuff that
00:26:44.820
matters you need to take your own applications your own benchmarks and run them on all these implementations to
00:26:50.580
really know whether it's going to help you so a true story one of my favorite jruby stories
00:26:56.700
um some years ago there was a large rails application using 40 extra large instances on ec2 and if you do anything
00:27:03.419
with AWS you know this is a lot of money to pay for these all the time 40 worker
00:27:09.179
processes per server to Max them out uh and they were getting about a hundred thousand to 150 requests per minute on
00:27:16.620
this uh 50 to 75 millisecond response times they didn't like this this is costing
00:27:22.020
way too much money for them to scale this application up so they took a look at jruby uh it took them a couple weeks
00:27:28.200
of replacing some libraries making some configuration changes uh making more use
00:27:33.600
of threading and not running as many workers that brought them down to 10 extra larges so we're talking a
00:27:42.480
75 percent reduction in your AWS costs I think that's worth giving jruby a try
00:27:48.620
uh and consistently they were doing better than 150 000 requests per minute
00:27:53.700
with lower response times so it really is worth the effort there
00:27:58.919
is a bit of work required to move to jruby but it's worth it to give it a shot for your application
00:28:04.200
all right wrapping up here man 30 minutes is short um so jruby Futures here so 9.4 is out
00:28:11.520
uh this slide has had 9.4 coming soon on it for years now uh but we finally got
00:28:16.919
it out there and we really want you to give it a try report issues let us know any issue that you have with it it's
00:28:22.919
probably not you it's probably us um maybe even submit a PR uh we're trying to move more and more of our code
00:28:29.220
into a ruby kernel within jruby uh so a lot of times if there's a missing
00:28:34.260
feature you could probably write it in Ruby and we'll accept that as a PR for for fixing it
00:28:40.080
uh lots of optimization work coming we're going to be doing several maintenance releases very quickly now uh
00:28:46.440
but I'm excited to get back to Performance optimization there's many different types of calls like super and
00:28:52.620
refined calls that we don't optimize at all right now um we're not doing any method splitting
00:28:57.779
like was discussed in benoit's talk so we'll start looking at heuristics for when it makes sense to split a method
00:29:03.539
that receives a lot of blocks uh and then there's a lot of interesting work coming up on the jvm itself uh Java 19
00:29:10.620
has now shipped experimental support for Native uh Native co-routines Native
00:29:15.720
continuations within the jvm which means we now can have native fiber support rather than using a thread to run that
00:29:22.700
uh there's also an early implementation of a jvm ffi that we can use so we'll
00:29:28.860
have support for Native calls out of the box without maintaining our own ffi and
00:29:34.080
then of course new jits new garbage collectors all the time so jruby on Rails future uh rail support
00:29:40.140
is very stable and there are lots of applications out there rail 7 is looking good uh We've Got Bugs we've got issues
00:29:46.440
that we know we need to work on but it's running and it was able to do all of the basic uh Blog blog application uh
00:29:52.980
actions uh so as your application grows maybe you should consider jruby we can
00:29:58.440
help your app scale up without adding more instances potentially uh reduced resources saving money
00:30:05.220
so grab me anywhere around the conference here I'll be hanging out after the talk I'll be at karaoke
00:30:11.520
tonight but let's talk a little bit about getting your application up on jruby thank you
00:30:17.880
foreign