 So, I'm not probably as recognizable as Mark with most of the people here, so I'll actually introduce myself. My name's Charlie Gracie. I'm a project lead at the Eclipse OMR project, and I'm also a software developer for IBM on the J9 Java virtual machine. I've been working on the Java VM for IBM for about 13 or 14 years now. So the same as the Oracle presentations, I work for IBM, a large company, and I'm allowed to believe anything I say. All right, so in my talk today, I'm going to be talking about Open J9. It's a project that we're starting to get underway to actually open source the entirety of the J9 virtual machine. So today I'm going to just give a quick overview of J9 itself, some of the technologies that are there for people who aren't aware that IBM has a Java virtual machine. Go quickly and cover the Eclipse OMR project because that's sort of a basis for the Open J9 project, and I'll get into Open J9 itself, and then hopefully we have a few minutes left to answer some questions. I apologize for my voice. I'm a little bit sick today. All right, so the real first question is why does IBM actually have their own Java virtual machine? IBM is a hardware vendor itself. They have their own hardware, P and Z series. They provide the OSs for those. They actually have a large middleware stack, and they have a lot of applications that they provide as well. So it kind of made sense to actually have the middle piece of the JVM actually there as well so that we could be sure that we have the whole stack covered. This allows us to have a high performance, high reliability, and a strong serviceability for our entire stack. The J9 VM itself is an independent implementation. A little bit later I'll talk a bit more, but we use a lot of the Oracle class libraries, but the VM itself is completely developed independently at IBM. So a quick little history lesson on J9. J9 was originally implemented as a Java MEVM, so the first few releases of J9 were all on different types of cell phones. You name the embedded board, and at one point or another we supported it. But as of Java 5, we actually became the IBM Java SE VM as well. So at that point in about 2004, our code base was actually shipping on the embedded platforms and all the way up to running on the Z390's mainframes. For the platforms we support x86, PowerPC, ZOS, ARM, big and little handy and whatever flavors of those hardware there exist. And even at one point, our VM was running on this oscilloscope. Okay, so quickly cover the architecture. It's a very busy slide, I apologize, but it was just trying to get a bunch of the details up here. So this is kind of the architecture layout of J9, and it even includes things you'll notice up in the thing under Java calls. Those are a bunch of the different ME class libraries that we used to support as well. So this is more of just of a quick overview to have everyone have an idea of what J9 looks like from an architecture level. So now I'll talk a bit more about some of the pieces of technology. So the actual interpreter, the core interpreter itself was rewritten in the last few years to actually be written in C++. It used to be years ago generated from, it was generated assembly from Smalltalk. We're all small talkers on the team originally back in the day. So when it came to having to generate some assembly, we wrote something in Smalltalk. So we've replaced that. It was very difficult to onboard new people, to actually understand, to have them work on this code. So as part of wanting to open things up and be more available to everybody over the last few years and even hiring new employees for ourselves, we decided we should have something that's more readable. So as readable, C++ code is going to be for it. So it's basically a large switch statement or computer go to. If anyone's seen an interpreter loop for any VM, it looks pretty similar. You look on the right. You can see some of the byte codes there as expected completely. We did, however, lose some performance by switching from the assembly generated one to having an interpreter in C++. But in the end, there was the trade-offs we felt to actually have something that we could have people develop and work on was worth the small startup time losses. And in the end, we were able to find other areas that we could actually improve performance. So in the end, we clawed it all back through other ways. As of the last Java 8 release, there were still small parts of code being generated from Builder. I'm happy to say, as of when we shipped Java 9, there will be no more of this auto-generated small talk code. Maybe here's some size or sadness in the back from some of the guys that love it. So the next thing I'll just go quickly into the garbage collecting technology that we provide in the IBM JDK. So we have really five-ish collection policies. If I had have taken a few minutes, I could have actually put this as the similar open JDK technology, I didn't have time. I didn't want to get it wrong on stage. So they kind of go from simplest to more complex as we go down. Vanilla op throughput, which is basically just marked sweep compact, does all of its work in parallel, as you would expect from something that's running SEVMs, but simple, straightforward, marked sweep. Up average pause has some concurrent collections for the globals. So a lot of the marking and sweeping can actually happen concurrently with your application. The generational collector GenCon, the con part is actually the concurrent collector from the up average pause, but then it does that generational collect for the new area. And then the one I'm going to talk a bit more about in a second is balanced. So this was new as of Java 7 and it's very similar type to G1. So it's our large heap region-based collector, provides a bunch of different capabilities that we can take advantage of. And I think we're sort of just getting to the starting to really take advantage of this as we see different large workloads and as new types of hardware kind of come online. And the last one is a soft real-time GC called metronome. So this GC actually, you have a pause time goal and then the sort of utilization that you want your application to get. So when you set those, the GC will, if you give it enough memory, will try to meet those goals. So by default, it has three millisecond pauses and will give your application 70% utilization. You can tweak those numbers in whichever direction you want. If you go really small and really high utilization, you probably need a lot more heap than your regular VM. But for the trade-off of having no large pauses, that's in some workloads a good thing. So quickly just give a bit more details about balanced and this will be useful to people too because it's somewhat similar to G1. So the heap in balanced is divided into a bunch of regions. These regions can allow you to do a bunch of different things. They can allow you to do things like gather objects with common properties into particular regions. So instead of just the normal GC behavior improvements, you can actually get lots of application type improvements as well in throughput by putting these objects closer together. If your objects that reference one another happen to always be moved around together, you'll have better locality. So when you're referencing from one to the other, it should be quicker. Because we have this region-based heap, we can actually very much target the areas that we believe are going to have a very high return on investment. So if objects are recently allocated, they're probably very good. That's the whole reason there's generational collectors. But there's also other things where we can recognize that we don't even want to touch large portions of this heap because they're never being used. We'll just assume they're alive until we actually ever need that memory again. And then you can do lots of other optimizations based on the actual hardware that you're running on. So you can take advantage of NUMA. You can use SSDs to offload parts of your heap that aren't actually going to be used or referenced very often. Now, so this technology gives us advances, advantages. And these are a lot of the things we're looking forward to as we keep improving the technology. Another sort of busy slide, but this is a quick slide on our just-in-time compilation. So as in OpenJDK, we have a very sophisticated JIT that goes through. This is kind of the different phases and passes that our JIT would have. And then, so the main part about our JIT is it will continue to dynamically recompile your code as it recognizes that things need to be optimized further. So this is kind of the regular passes that it goes through. Usually it doesn't skip any passes, but it can in certain scenarios. So you start off with cold, warm, hot, and go to scorching. There is a profiling phase in the middle, so that one will actually just be generated to gather more data to be able to go do the very heavy weight scorching pass. Once a method reaches scorching, it won't be recompiled again. That's as much as we believe we can do for it. So that's the end of where it'll be compiled. Yeah, quickly. So there is a profiling thread, but when they generate the profiled method, they'll actually generate some counters and things within the method to actually gather data. Another sort of unique feature to the IBM JDK is our shared classes cache. Now, so coming originally from our ME days, we used to run on lots of systems that had lots of RAM, but very little RAM. So to be able to run things efficiently, we started dividing our classes into what we call a ROM class and a RAM class. The ROM class portions were always being burned into ROM on the phones. So when we came around to SE, we decided that we could keep that distinction there, and then you could actually share these ROM classes across if you're running multiple VMs, or you could actually have a cache so you could load quicker on startup using shared memory. Once we had this cache and were able to share, we realized, well, you do lots of JIT code as well. So for things like startup when you're going, you can actually go and store some of our AOT code in the shared classes cache so that when you start up, you'll actually get some pretty noticeable startup improvements. And here, the memory footprint on a lot is by about 20% and usually you can get about 10 to 30% in startup speed by storing your AOT code and ROM classes in the shared classes cache. An obligatory performance chart. This is just sort of some performance numbers over the different Java releases showing that IBM is really focused on the performance of this and that's going to be a continued thing for us as we move forward. So quickly on to EclipseOMR. So I'm here to talk about us open sourcing our Java VM. The first step to this was actually, we started last May, we open sourced a large portion of our VM technology already. So you can go look at it on GitHub right now. There's approximately 800,000 lines of code there. This part is actually the language agnostic parts of our VM. So if you look at a garbage collector, you have to know what roots and what the shape of your objects are, but marking and continuing to go find everything recursively, those parts sweeping your memory, giving it, reclaiming that stuff, that's very common. There's no language specific parts to that. So as we were looking at this over the last few years, we decided, well, let's take all of these parts out and we can make them available as a toolkit for other runtimes. So part of our open J9 will actually be consuming OMR because that's what we're actually doing internally now. Every change that happens on GitHub shows up in the IBM JDK builds, usually the same night happening internally. So right now, this is sort of the quick components that are out there in the Eclipse project. It's our porting and threading libraries. I call it VM, but it's just sort of pieces of data you'd have to know like some thread information or the actual VM structure. So things that we need global data to be able to talk and communicate between the components are GC, the compiler, JIT builder, which is another project that we're doing to make using a JIT for your language easier, and then trace FE tests and a few others. But like I said, it's approximately 800,000 lines of code out there already. So to kind of move on to open J9. This is like quote from our CEO at the time, maybe still is. That IBM is really focused on growing partnerships and the open source communities that we're involved in and we're actively trying to be involved in more communities. It's very key to how she believes how IBM and I actually myself believe that's kind of the key way that we're going to move forward with a lot of our technologies. A lot of the open source projects out there are really driving the innovation in a lot of areas. So we want to be out be a part and hopefully helping drive some of that innovation through these different projects. So why really are we doing open J9? I just said it's good. I think it's a reasonable thing, but the biggest one for us is collaboration. So anytime we want to work with a partner, work with universities, work with the actual rest of the Java community, we're behind a closed door. There's basically a wall in front of us that we're shouting over top, maybe hearing some of the details coming back. So this really will allow us to be out there and actually collaborate with everybody, including the rest of the open JDK community on a really high level. We're hoping that it also will help with rapid innovation. If you look at early 2000s to mid 2000s when the Java benchmark wars are going on, having multiple independent VMs all competing to show the best performance. You saw Java make huge strides in performance over those years. So we're hoping that by having multiple VMs in the open now, Java can actually help with the collaboration and innovation at that level by having both of them or multiple VMs out there. So the wear of open J9. So I just said we really want to collaborate with the community. We're hoping that we can actually have the open J9 project become a part of the open JDK project or be a project on open JDK. So right now we always take a bunch of the open JDK class libraries, mix in our VM and that's currently how the IBM product happens. What we'd actually like to do is consume open JDK and then just turn that into our product which in the end by if we were using open J9 as part of it, that would also be consuming in our OMR clearly. But this is kind of where we would like to be in the end. So if we were there, how would you actually do something? This isn't for sure, this is kind of just our thinking along the lines right now or my thinking at this point when I put the slides together is if you actually cloned the open JDK repo, there's this get sources script there already that will go and get you with the whole rest of the forest so that you can go and compile the JDK product itself. We would actually like to just be able to plug into that so you could get the J9 sources as part of that if we were on the project. At that point, then you could just configure maybe a simple option like this, like with open J9 and then when you did your regular compile, you would actually just be fully compiled and running J9. A simple make clean and configure with hotspot or without this and you could be using the other VM. So this is kind of where we would like to end up ourselves for the open J9 project when we're doing all of this development work alongside of our Java 9 development work. So it's just actually our developers trying to make progress on getting the code ready, going through cleaning everything up so that we could open source it. So that is but also having the developers do it is kind of keeping us honest. Anything we do to get ready to go out is also being consumed right back into our products so it's kind of making sure that whenever we do deliver some to open J9, it will be working. It will be the exact code that we're shipping in our Java 9 project. And so we're hoping to have the initial release around the time of Java 9 GA. So kind of in closing, so for open source as a team and an organization at IBM Runtimes, we really want to be doing most of our work in the open. We've already started with the Eclipse OMR project and hopefully this year we also have the open J9 project coming. Any questions? Frisco? So that was the slide where I was talking about when we supported ME, if I go back. Do you only have one hotspot? Do you only have one virtual machine serving all the JDKs? And I wonder whether you saw this correctly. That's correct, yes. How is this working for you? So some of it is compiled time decisions. So it's one code base. So some of the decisions and we have some of the core classes ourselves that we provide. So yeah, it's basically a compile time with a few runtime decisions based as well. So what about license issues? You're afraid of combining the Apache code with GPL v2 and class pass in the class library? I don't actually have much details on that. I'm not a lawyer. I'm going forward with this is where we would like to be. This is kind of what we want. I'm hoping other people can make that sort of decision or figure out how to make that work for us. Okay. Sorry, there. That's J9 Super GPU of Upload? Yes, yeah, as of Java 8 we have GPU support. What platforms are you planning to support initially? So the first version that we get out there will support the three linuxes that we support. So Linux x86, Linux PowerPC and Linux 390. That will be the starting just to get something outgoing. And then we'll fill in the rest of the platforms as we go forward. I just wondered you could just start off by forking OpenJK and then like be a fork of OpenJK with an additional build option or would that be an option? Is that your way you are going? I don't think we're quite at that point of deciding if we would fork and do something there. I suppose that could be an option. But I guess there's just more talking and we'll figure out where we're gonna really land. What will you call J9 when Java 10 comes out? And more importantly, if you strip the version number you just have J is not a little bit confusing with OpenJ, OpenJDK. Yeah, the J9 comes from a long time histories for the code name. We're calling it OpenJ9 right now. It could change to something that isn't quite as confusing for especially around Java 9 time. Is the goal to have everything open source or are there gonna be like commercial features and stuff like this which are separate? Currently right now, as far as I understand it is not to be any extra, we're gonna open source everything that we ship right now. If there's extra applications or other things that ship as part of our JDK, they may be separate. But as far as I know, most of the code will all just go out as the open source. Okay, I think I'm actually over so I will stop here guys.