Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
all right all right get started on slides my name's Charles not the janitor project just quickly many people here that's way staff and how many people know very little about jruby okay well I'm glad we put these slides at the beginning so we'll
do just a quick couple minute description of what is jruby JRuby is quite simply just a ruby implementation built on the Java platform and because of that you get all the advantages and disadvantages that come with being built on the Java platform if you have
a issue with garbage collection you can go and change your garbage collector and tune different parameters to go and fix that it's got an awesome and it does a bunch of profiled optimizations which I'll be talking about in a few minutes lots of tools
we run on crazy platforms you run on openvms we run on an IBM mainframe and probably the most visible change here against see Ruby is that we fully can utilize native threads because Java platform provides native threads right another major feature of JRuby
is you can go and pull in any Java library and interact with that as if it was a ruby library so you'll think that you're actually calling a ruby class but and the fact it will be a Java class and so imagine for a moment that you're trying to do
something with PDF generation and the ruby gem that you're using just doesn't quite do it you can always pop over and try i text which is a popular Java PDF library and and probably get what you need likewise you can actually just call in two different
languages and this different language will run in the same vm as jruby itself probably the most popular example right now is a deployment style called mullet like the hair style so they do all this serious business us with closure on the back and they use
jruby on the front with rails kind of kind of a reverse mullet I guess party in the front business in the bag okay so that was like a minute and a half description at JRuby if you want to know more about why Jay Ruby's interesting in those regards there's
lots of talks and lots of stuff online we have lots of slides will go more into depth on what JRuby 9000 is and what we're trying to do with it now so our two main branches of development is master which is for the upcoming Jeremy 9000 release which this
talk is about and we have a maintenance release for JRuby 174 JRuby 17 itself it's a multimode release so if you want to run with Ruby 18 compatibility or 19 compatibility you just pass a command-line flag and it just behaves that way we decided not to
do that anymore so for junior be 9,000 we're just going to follow the latest Ruby release which we're targeting Ruby 22 which isn't actually out by see Ruby yet we're pretty excited about finally being caught up with MRI so now we can kind
of move in lockstep in the future so we wanted to put out a preview release for this conference and we didn't quite make it but then we decided that that was a good thing because it'll give everyone here an opportunity to try JRuby and give us some
feedback right well the better preview as a result as long as we get some of you folks to try things out let us know what's going on and as Charlie just said it's really exciting we plan on having a final release towards the beginning of January which
is only going to be a few weeks after see Ruby puts out there to to release I think this is the first example I know of two implementations releasing that close together with new feature really its own and we we put out new releases of 17 every three to six
weeks so in the next week you should see 17 17 so as I said jruby 9000 is going to target Ruby to to support we have a new runtime which I'll be talking about in a couple minutes and we've totally revamped I oh and encoding support which Charlie will
be talking about and removing a bunch of crap which I just said so I wanted to go and since there's so many new people coming to rubyconf I wanted to cover Jay Ruby's warm up this isn't real but we do actually see similar statements like this online
all the time this is usually like people's first reaction to trying JRuby out they run some tests and it doesn't run as fast so they gave it a you know they gave it a quarter of a second so let's start with three definitions the first one is startup
time this is just how fast it takes to start executing anything at all on this is typically only relevant if you want to make a command-line tool and Ruby and it's not going to run long after that there's this middle phase where codes running but it's
not running as fast as it could run because your vm hasn't optimized it yet but once it has optimized it then you end up hitting this steady state where the vm is essentially done doing any optimizations so a graph might help with this so if we look at
the blue line this is see Ruby it's actually a pre-release a tutu but I think it's about as fast as it runs this particular red black tree benchmark but you'll notice across each iteration the number of seconds that it takes is the same it doesn't
change so there's no warmup if we look at the yellow line this is jay Ruby with Java sevens invoke dynamic support you'll see at the beginning it's quite slow and so it's got a fairly dramatic warm-up curve but by iteration six it's sped
up and it's running quite a bit faster we aren't so happy with the current state of warm-up for invoke dynamics so for right now our behaviors the red line which uses almost nothing from invoke dynamic but you can see that the warm-up curve and the
initial startup time is pretty good this is the current state of see Ruby they go in parse Ruby they generate a set of virtual machine instructions which represent Ruby semantics and then they have an interpreter that just walks these instructions mots hinted
that in the next year or two that they'll probably make a jit and it'll end up looking something like this which is Jay Ruby's current very broad architecture but again we go in parse Ruby we generate a set of virtual machine instructions that
represent Ruby semantics though different instructions from MRI and then we run an interpreter on it now if we execute that method a lot then we go and pass it off to the JIT we generate java bytecode and then Java goes crazy on that and optimizes it so some
people might wonder why we don't just get everything make everything fast well it comes back to that first definition of startup time we need to get off the need to get out of the gate as quickly as we can because a major problem with JRuby that we've
had for a while his startup time Charlie's going to be talking a little bit about how we're addressing this now and in the future later but the other thing is every time we go and get a ruby method we generate a Java class then we have to pass that
off to the JVM now the JVM just keeps getting more and more classes GV I'm smart it knows that if it receives a class and it's not hot it's not going to do anything with it so it's just going to sit in the JVM bytecode interpreter so it's
just wasteful to even bother but primarily startup time is the reason why we do this okay so the recommendation for people that are new and want to do some benchmarking is you can use a tool like perfer or benchmark IPS these basically have these rehearsals
which try to get rid of that warm-up time from the final numbers that are reported and so I spent several minutes to say just use these two tools some people might wonder why there's even a warmup time it was somewhat obvious maybe from the previous slide
[ ... ]
Nota: se han omitido las otras 3.894 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.