 All right, it's 11.25. I guess I'll get going. Today, I'm going to be talking about Cloud Native Java with OpenJ9. I'll talk more about OpenJ9 as I get going. But it's basically another, it's an alternative open source Java VM that you could be using in your cloud environment. And I believe it would actually be a big help and improvement and cost savings for you to be running this Java VM in your environment. My name is Charlie Gracie. I am the garbage collection architect at IBM Runtimes for the J9 Java virtual machine. And I've been working on VM technology for about 13 or 14 years. Kind of feel a bit bad every time I present that. It gets longer, a bigger number. Some contact information for me if you want to get in touch. Twitter, GitHub, they're all easy ways to get in touch with me. Some important disclaimers. Don't base any of your business decisions on what I say today without verifying them yourself. Things are subject to change, that sort of thing. So today, I'm going to be sort of quickly cover the economics of cloud and Java. I assume most people are aware of this. But I'll quickly go through it just so that I can set things up. Then I'll talk about Java for the cloud and OpenJ9. Talk about some of the features that OpenJ9 has that I believe will actually be quite helpful for people running in the cloud. I'll give a quick demo. It's nice to talk about the results. But I'd like to actually show you these wins. So we'll hopefully see that all of my stuff works. And we'll do a live demo. And then I'll go through, wrap up, covering some of the results, and opening it up for any quick questions if we have time. So part one, cloud economics of Java. So in the cloud, footprint is really king. Everybody is probably well aware that you are paying mostly for your gigabytes per hour of RAM. So this is really the new measurement cost that you're beholden to when you're working in the cloud. If everybody is familiar with Java, it can be somewhat of a pig-on memory at times. And it has been over the years actually sort of optimized to be running on a giant system. So the myth with Java is that RAM is cheap. There's plenty of it. And you can just add more RAM. That's true when you're running on-premise and you actually have a dedicated machine to run some application. But as you move towards the cloud, that's not actually true. The reality is application footprint is very important to actually the cloud providers themselves and to applications running. The users, it's a clear thing. You are going to pay by the amount of RAM you're using. So any improvements in RAM can actually save you real dollars. And for the providers, smaller footprints actually help them in a way as well because they actually improve their density. They have these really large machines and they want to virtualize them as much as possible. So smaller footprint actually improves the density per machine for them. So the big trends are these big machines being virtualized into smaller machines and microservices. See a really big push there. And this is actually increasing memory usage in Java in particular. So the Java VM footprint is really important. So there's a distinction I want to make sure we clear up here. So the on-disk image size of the VM or whatever runtime you're doing, that actually is very relevant to the cloud providers themselves. This is where they would improve their density in a lot of cases. And also if you're actually migrating instances around across from one image to another, the copy times of doing that actually are also important here. Virtual memory footprint is in particularly important for a lot of 32-bit applications. So if you've moved some older applications to the cloud, this is important. But that's not really going to be the focus of my talk today. It's actually going to be on physical memory footprint in your RSS. This is what's very relevant for your applications. A lot of the time, this is how you got more performance as you threw more heap at your Java VM, take those nasty GC pauses out of the picture, and consume as many resources as possible on this machine. As well as the Java VM being a problem in this area, something needs to be improved, your application itself, when you were running on these very large machines with lots of RAM, could easily get more RAM because it was super cheap, small little things weren't always paid attention to in your application. Are you allocating a bunch of extra objects for every transaction? Actually, you don't really need to. Have you in keeping some debug information around at runtime or extra logging that doesn't really have to be there that's keeping your footprint much larger than it needs to be? And this is just a simple example that even a small drip can actually waste substantial amounts of memory. Oh, sorry, I have water over a year. So this is something that as an application developer now, you may actually, as you're working in the cloud, have to spend a bit more time looking into and figuring out this part of your application as well. So what does all this mean to Java developers? Changing your XMX directly affects your cost. This is very easy for anyone in your business chain to understand and follow, because if you shrink it down by, say, half, they'll save half their money on every run. The net effect to this is really that you're going to be tuning your application to fit into specific RAM sizes. So a lot of cloud providers will actually charge you based on some sort of increments of different amounts of RAM sizes. So a 64-meg and under is a certain price, under 128-megs or 512-megs are different price points, or that's when they increase the price. So you may actually see a drive to run your application, move it down from the 512-meg to, say, the 128-meg, just to save more money as well. So for this, you'll need to understand where your memory is being used, and it may actually drive you to switch to other components they're using. You might be using an open source component for something, but this one may actually consume more memory, so you may switch to another one, even though it causes you a bit more grief in your application programming itself. It's a bit harder to use of those things because the trade-off might actually be a significant win for your company in terms of how much money they pay to run these things. And the big thing is any small increase in one service can actually add up to huge money as you scale out. So if you have multiple concurrent instances running to handle your workload pressure, you may actually pay pretty significant money here, even though it's just a small increase in this one service. So part two, Java for the cloud. I talked about things you might have to change, but the VM itself should actually be able to help out a lot here with improving your ability to run and save money and have a better environment in the cloud. So quickly here, OpenJ9 is another version of a Java virtual machine. It was open sourced in September 2017. It's not a new VM. This has actually been IBM's Java virtual machine since the 90s. So it's just now been open sourced. Might have lots of questions about why we did that. We have all kinds of talks and information, but quickly it's just to actually be able to get out and be more involved with open source communities. Lots of people are working in the open source and would prefer to work with that types of tools. So it's a direction we're going to actually see if we can get more outreach with the different communities. To get your VM, there's a great website called adopt open JDK. It's actually being run by the London jug. They actually are producing open JDK binaries with hotspot with open J9 and any other vendor of a VM that has an open source VM and you can go download prebuilt binaries. This sort of removes the distinction of where you go get it and what happens to be in your runtime at any one time. Depending on where you're getting it, this is a great place. The one last thing about adopt is they actually also push Docker containers built up that you can grab as a base with all of the different JVMs as well. And I'll show a bit more about this later as I'm talking about some of my demos. So why is open J9 good in the cloud? Well, I'm going to take a big step back into the 90s. It was originally started out as an MEVM. If anyone's familiar with like the most iconic phone in the world, this was running Java back in the day for your games and lots of other little things on the phone. So Java ME actually at that time had a lot of requirements that you may feel similar to what you're going to be doing in the cloud. They required a very small footprint on disk and at runtime. They had very limited RAM. We're talking small numbers of megabytes here, four, eight, 16, if you were lucky. But usually you had some more space in ROM so that actually helped make some decisions about what you could do with your application. If you could burn things into ROM that actually gave you a bit more space. They required very fast startup. If you're launching your Java game 10, 20, 30 seconds you're not going to be wanting to play if it's not started up. And they wanted a quick immediate ramp up because you don't want your game to actually accelerate or change as you've been going. So they want a very consistent feel to how that's actually running. So, and that's another differentiation as startup is getting up to the point where, in my terms of to the point where you can run your application main and ramp up would be till you get sort of peak throughput. How long it takes you to go from your transaction in that type of world from taking 30 seconds down to your one second at your highest throughput. So the cloud, it's very similar. It needs small footprint. They want a fast startup and the quick immediate ramp up is really sort of key to also saving you money and your gigabytes per hour. If you're running your transactions very quickly at your max throughput, that means that when you start up a VM for some sort of like serverless or a quick microservice you're actually getting your throughput right away. You don't have this 10 minutes, 20 minutes, an hour to get to peak throughput because you might not actually run that long. It might only be 30 seconds, two minutes. So you need this very quick ramp up as well. So some of the key features in Open J9 that I believe actually really help in this area and it will be quite useful in the cloud is our share classes cache. This is the quick options. The first one just enables it. There's all kinds of sub options. You can look up later. It's very well documented. And the big one I'm calling out here is the size. So how big do you want your cache? Share classes cache is really doing a couple of things. So the first one is it actually is used originally to cache our class files. The class file format in Java, to be quite honest is not very great for the VM. So when we're loading these classes we actually load it up and turn it into our own format and makes it much easier for us to use and optimize. But if you think back to our old days as ME, Java ME developers, if we had to put all of the stuff in RAM that's very limited. So what we figured out was there was actually lots of parts of a Java class file that actually do not change based on your runtime. So what we actually do is we divide this class file into a ROM and a RAM class. Very well named because of what they were used for originally. And the ROM class is basically a position independent movable piece of code that is the same. If you load the class A 10 times you would get the same ROM class for it. To basically at runtime if you were changing fields or things within an instance of that those things would be tracked to the RAM class. So with the share classes what you would see is if you had multiple JVMs you would actually have some ROM classes and some RAM classes. But where the big payoff actually comes is when we actually put these ROM classes in a cache. So at this point they're in a memory mapped file that they actually would end up being shared across all of them. So when you load up a class the first thing you would do is you would actually go check is it in my RAM class already or is it in the share classes cache? Yes, you've already got this pre-built piece of data for you already for that class. That improves your startup and it actually makes for a quite a bit smaller footprint if you're running multiple instances on the same piece of hardware. Because this memory would actually only be a account at once and all of the other versions instances of the VMs could actually share the same data. Another feature that we actually get through the share classes cache is dynamic AOT. AOT actually stands for ahead of time compile. So this is actually for JIT compiled code. What it actually does is when you're in startup mode our dynamic AOT cache will actually check to see when it's time to JIT a method. If it should JIT it, if it should that is it in the cache use it exactly the same as we'd use a ROM class so it's actually much quicker to get to it. You don't have the time to compile. If not go compile it and then stash it in the cache for the next time. So with share classes and AOT you start to now have a distinction on startup of a cold and a warm startup. The cold startup would be the first time as you're populating the cache and then once you've run through your application once you would all be warm runs after that because then you would hopefully be getting all kinds of hits from your cache. And this second and more runs of the warm cache that's actually we start to see some pretty significant startup time improvements from simply just adding the command line option and providing a bit of space. So in general the AOT loads are over 100 times faster than compiling some of the complicated JIT methods but there is a slight downside. This AOT code because it is actually shareable and not as highly optimized. Sorry, because it's shareable we can't actually do some of the high end optimizations and you can't always make certain guarantees about which classes would be loaded in the system already and things. So it actually is slightly less optimized than a full compile that the JIT would do in your normal runtime but because we actually have recompilation in the VM you would run the AOT version for a while if it still something needs to be optimized the JIT would just kick in and go compile it again and optimize it further. A few of the other things that are there is we actually have this X Quickstart option. This is mostly a JIT tuning option and this option will actually reduce the counts that it would take before you would go compile a method and tweak a bunch of the other decision making so you actually compile quicker. It's to actually give you the quickest startup possible to get through your application and up to the point where you're running your main. This again would be more targeted towards sort of short-lived tasks. Short-lived, I'm not talking in the small numbers of seconds or milliseconds here, this is probably in small minutes to tens of minutes and it may have some, it may limit your peak throughput and we'll see some of that later on in some results. X-Tune Virtualized, this is sort of a grab bag option in our VM right now where anytime we find out, figure out something that can help in a virtualized environment we sort of enable it under this option. So this will actually tweak some different options for the GC to tell it not to expand the heap as quickly, those types of things to favor reclaiming memory so it also enables some idle management. So if your application goes idle for a few minutes, why do you have all of this RAM still committed into the Java heap if we have free space that you're not using? Let's go contract it down and be even more aggressive on the little bit of free space we'll give you because we can always go re-expand again later if we need it. So again, if you have some peaks where you're up and down in your amount of transactions this might actually come in very handy to reduce the amount you're paying at any one time. And it does other tweaks to improve startup and ramp up as well. This one has a smaller trade-off in performance and it's usually around actually GC times. You would have a slightly more overhead in the number of GCs you would actually end up having. All right, so part three, some demo. Let's see if this works here in my display so I can show you a few things. So what I have here, what I'm gonna demo right now quickly is I have a Docker image. I have actually a few of them. I'll show you the Docker files quickly. I won't build it now because it takes about 30 minutes. That's not quite in my time slot here. But I have one built for Hotspot, one for OpenJ9 with no options and one for OpenJ9 with the share classes cache and QuickStart enabled. And I'll just show you how quickly this application can start up, sorry, the container and the application will start up with this enabled. And then we can look using some of the Docker statistics on the footprint and CPU that's being used after it becomes idle. So quickly, so it's a pretty small Docker file. Sorry, you probably can't read it. I apologize, I thought it looked bigger. Basically, all it's doing is starting a base from one of the adopt OpenJDK Docker images I mentioned before where they build the different VMs. Going through, it's cloning a spring pet clinic demo to start up that that's what I'm gonna use later. And then it just has the simple Java command line to go launch this demo. So that's pretty straightforward. Make sure I have nothing running right now, perfect. So that actually would have been built and so now I'll just run it. And I won't adjust the screen until it's finished. I don't wanna interfere. I picked this app because it actually prints out at a great time at the bottom of how long it took to start up, which probably can't see, which is 9.5 seconds. I can run this a bunch of times. It's very consistent on my laptop, but that would actually be for the hotspot. Now the J9 one, all I did was pick a different VM. The Docker file for that one was just a different base. So here we go. No real difference in performance at this point. They both took about 9.5 seconds to start up. But if I go back here, you can see this is the interesting part. For the two applications running right now is the memory. The top one, I can tell you is open J9. I'll do a Docker PS in a second to prove it, but it's actually only using 162 megs versus the hotspot one, which is actually using 450 megabytes. So this was getting the application up and going. The CPU is still going here. They slowly slow down. Both VMs actually become more idle over time, but that actually right away is quite an improvement in your footprint. For just a simple application to start up, it's actually using less than 50% of the memory. So the next thing I'll actually start up is one of the J9 ones with the shared classes cache. I've called this cache cold because it actually doesn't have a cache in it. It's going to actually build a shared classes cache while it's being launched. So I call this one the cold run. And when we see this image actually get loaded into the container, it's actually gonna take longer. It's gonna probably take about 11 or 12 seconds because this time it's actually going through. It's actually doing a lot of checks and getting only misses in the cache and doing a lot of writing out to the cache in your first startup. So if you were actually going to use the shared classes in your deployment, you would actually build your run. You could actually mount a volume to actually have your shared classes cache so it could be shared across everything on the same physical machine in there. Or you can actually just pre-populate your image as well. So it would increase your Docker image size by whatever the size of your cache is, but you could actually have it just pre-populated directly into your image. So yeah, this one took 11.5 seconds to actually speed things up. And you can see it's actually using even less memory. So I'm gonna do Docker PS. And to save ourselves a little bit of time, I'm actually going to just commit the current cache as one called warm. And then I'll just go run that guy. And since this actually now went and created the image based on the one that was there before, which would have a completely populated shared classes cache, you can actually see that we started up in about 7.6 seconds. So we save about two seconds on startup of actually getting your container up and going out of nine seconds. It's actually pretty impressive to me. And if we go back and look at the Docker stats, before I do that, I cleared it anyway. All right, well, you can see all of the open J9 ones are actually in the small numbers of hundreds of megabytes. And the top one is actually the warm cache. And the reason it has an even smaller footprint is it's actually getting the win of using the cache that was from the other one, I believe. Actually, no, sorry, I don't have a shared volume. That's not true. They're always roughly within this small number of megabytes, depending on how much the odd on this detection is kicked in, because that would actually be running here and moving things around as well. So there, that's sort of my quick demo here on the different improvements you can get quickly just by using some shared classes cache and that it's actually quite straight forward to do it. So I'll move on now to wrap up quickly. The startup time with that quick demo was about 30% faster and that's pretty much something you can measure across the board. The first few times we published this after OpenJ9 came out, a bunch of other people were like, oh yeah, sure, it's in some random benchmark. They've actually gone now and run their applications and have mostly come back and been tweeting about it as well with this amount in the 20 to 40% faster on startup. The footprint is 60% smaller with OpenJ9. That starts to be in the order of cost you can run twice as many in your environment for the same price or you can pay half as much depending on how you look at it. So that's actually pretty impressive. Something that we would have had to wait a little bit longer to see in the run was if we let the CPU go down, OpenJ9 would actually only be triggering about 55, it would be triggering 55% fewer wakeups and which is easily tracked through the power top tool is what I used to gather this data on a longer run. And in this chart we couldn't really, I didn't have time to show, but this is a run using day trader and it's actually showing the difference between a few of the options. So red is just OpenJDK9 with hotspot and the blue is just a regular OpenJ9. But it shows that we have a bit quicker rental but that's not the thing I really wanna call it here. It's actually the green line. So this is actually using a shared classes cache with AOT and using the Xtune virtualized. This is actually giving you so much more ramp up than you could get in the other two modes. And if you look compared to the hotspot one, you can actually run for a significant amount of time before you would actually get to where it would cross over. So if you were in some sort of serverless environment where your VM will be up and running for a few minutes, five, 10 is usually about the refresh time of VMs there if they're being shared. This would actually give you all of the throughput like max throughput that you're ever gonna get very quickly without costing you any real throughput. So sort of in the end here, cloud is sort of new. I'll put that in quotes. Everything's really changing. Developers are learning a lot about how to actually work in this environment and to how to save money, how to do things cost effectively there. The JVM itself is also doing this. There's lots of we have to learn to be able to actually get through and make further improvements so that we can provide the best VM that there is for people. And we have more things coming as we keep going on. There are just not as much time here to get into all the technical details of where we're going and things we're adding. But the VM itself will continue to improve as well. And that's it. Thank you. I think I ran rate up two times. I don't know if I have much time for questions, but I don't know if I have time to ask. I guess so if anyone has any questions or I can quickly, yeah. I think you would still be able to see most of the benefits that I was showing. I'm not super familiar with Spring myself and the way things are loading up, but with the shared classes cash and AOT, you should be able to, you just may need, if they're preloading a lot of things, you just may need a larger cash. So that's just something you could tune and start up and change on your own and sort of measure. If nobody has any other questions, I'll be around outside if you want to ask questions then too. But thank you guys so much for your time.