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.  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.  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.


For the CircuitPython Parsec today, I wanted to show how you can use the pixel map inside of the LED animation library to separate a NeoPixel strip into different logical groupings. So one physical strip, multiple logical groupings, it allows you to do some really neat stuff and essentially in code treat this like it's two strips. But you can see here, I've got one ring here. It's a ring of 24 NeoPixels, I have a little diffuser on there to make it a little easier to look at under the camera. And I'm using two separate Comet animations running at different speeds with different colors treating it like two strips, not four, but two. Here's how we do it. In code, I am importing the board library to get pin definitions and the NeoPixel library. Then I'm bringing in three sections of the Adafruit LED animation library. I've got Comet, which is the animation effect that I'm using here, a couple of color definitions, purple and green, and then this pixel map business. So I set up the strip, and you can see this is the normal NeoPixel definition, so I'm just saying it's a 24 pixel strip on pin A1, and I'm setting the brightness pretty low, 0.05. Then I set up these two logical pixel map groupings, LED's range A and LED's range B, you can name those whatever you want. And in there, I use the command pixel map, LED's, which is the NeoPixel strip, the range that I'm using, the first one goes from 0 to 11, and then the second one goes from 12 to 23, just tell it the outer bound number there. And then I'm setting up a couple of these different animation objects for Comet. Then I fill the whole thing with black, so it turns them all off, and then the main loop of the animation just simply says, run those two animations. So any changes you want to make to one of these, you can do it, and it doesn't affect the other one. And so that is how you can use pixel map in the LED animation library to set up multiple logical groupings of NeoPixels on a single physical strip. And that is your Circuit Python Parsec.


What's going on everyone? Sam here with Layton Sports Guard. Just doing a three box mixer for Jordan Q. We got one 22-23 Panini Crown Royale, one 22-23 Panini Donner's Optic Choice, and one 22-23 Panini Obsidian Basketball. So good luck here Jordan. Start with your optic choice. Been for a mega, keep me going all night. Good Lord. See how new you are. Auto Porter. Oh do we have a... I don't know what that is but we'll do that last. Marcus Smart. Dragon Scale. Black Gold. Kenneth Lofton Jr. Five of eight.  Rookie Flory there Jordan. God Jeremy Sohan and Benedict Mathering. Evan Forney out of 88. It might not be a Nebula. I've not seen this parallel before though. Looks Nebula-ish. Auto Porter. Shade on Sharp. That is going to be... No, not a Nebula. Rick Berry. Just one... It was one of the throwback autos that's why. Nice one there still. Rick Berry for the Warriors. That was a troll and a half right there. So it's like that. I don't think it's a Nebula. It looked like it but it doesn't look like anything I've seen. Right. It's still a nice one though Rick Berry. 22-23 Obsidian now. 22-23 Obsidian. Devon Vasell to 99. Orbital coming to 99 as well. Herbert Jones. Malcolm Brogdon. And Drew Holliday. Cool one here. 95 of 149. Carl Landry on the Lightning Strike Auto. For the Kings. Carl Landry. And 73-75. Max Christie on the Obsidian Rookie Eruption Auto. Yeah because we got... That actually works out well. I'll tell you why after. Okay. Cool. Not a big deal. Cause like well, not even. Finally. Nice one there. All right. See what we got. Leave the kabooms in here. Rudy Gobert. Ant-Man. Jalen Green. Paul George. And Cole Anthony. Got a Blue Crystals to 99 Bradley Beale. A regular Crystals. Scotty Barnes. That is a Malachi Brand. I'm 2 of 10 on the Gold Auto. Gold Die Cut. Crown Royale Auto to 10 I suppose. And Knights of the Round Table. Game used Jersey. Julius Randall. Very solid. It's going to do it for your break there. Jordan. Thanks again for your support buddy. We'll get him right out to you man.


A project network is probably one of the most critical pieces of information that a project manager needs in order to correctly plan and conduct a project. The project network takes all the work packages from the work breakdown structure, puts them into a network depending on their dependencies, and then from that we can make all sorts of other calculations. We can determine when the project will end. We can determine which tasks are along the critical path. We can determine which tasks can be delayed if needed within our project plan. We also can figure out how we're going to have to allocate our resources over the project time period. We'll also know what is our cash flow going to have to be over the project time period. So a project network is a critical document that every project needs to create at some point or another, and there's basically two approaches to creating a project network. The activity on arrow, which is kind of self-explanatory, as we'll see in a bit, and the activity on node, which is also self-explanatory. Let's take a quick look at this. Activity on arrow, I say it's self-explanatory because we see that the activities are actually represented by arrows. You can see that the length of the arrows may sometimes be used to indicate the relative time that's needed to complete a given task. Sets are where we actually have our tasks intersect, so they are what in some ways provides information about precedence here. And we have a starting node is also referred to as an i-node, and the ending node is a j-node. So for example, you'll see task A's j-node is task B and D's i-node. In each project, when we use an activity on arrow diagramming technique, we'll have a starting i-node and an ending j-node. This technique was used a lot, especially in software planning. It's not used quite as much anymore. The dominant technique seems to be the activity on node. So let's explore that in more detail. Here once again it's somewhat self-explanatory that activity is represented by a node. These nodes do not vary in size or anything like that to indicate their relative amount of time that they take. They are just ordered in a network such as you see here. So the activities are shown in nodes and boxes. We can then tell the precedence from the way in which these boxes are arranged and the arrows are used. So for example, with task D here, we know that task D can't start until both tasks A and B have completed. And the project has a start and an end as well. Now how do we go from having a list of tasks or work packages that we know that we need to be able to complete in order to complete the project to actually having a project network? Well, there's a number of rules that we can follow. The network is going to flow from left to right. An activity can't begin until all of its preceding activities are completed. We're going to use those arrows to indicate precedence. We're also going to identify each task with a unique identifier that can increment in some way or another in a logical fashion. So if we use the numbers 1 through 20 to indicate the tasks in our project, we're going to number our tasks in a way such as we know that task 10 is going to come after task 1 and prior to task 20. We're not allowed to loop through this network. So there's no looping that's allowed. We can't repeat a task several times throughout a network. Conditional statements such as ifs and ors and things of that nature are not allowed. And we also use start and stop nodes. A couple of other pieces of terminology before we get started actually making a network. Activity. It's something that actually requires some amount of work or time. Parallel activity is in this case A and B. We have two activities that can occur independently and if desired they can occur at the same time. But there's no dependency on A getting done before B can start or vice versa. We can also have a merge activity. In this case activity D is a merge activity where A, B, and C have to be completed prior to D being able to start. We can also have the opposite of that which is a burst activity. In this case A is a burst activity. It is the predecessor for both B, C, and D. We can also have a milestone. Milestones are simply markers in our project for when we complete significant events or significant deliverables and that a milestone does not consume any time within our project network. So what we're going to do is we're going to take these various tasks that we've listed these various work packages and we're going to talk with the experts in the field or within our organization on what the dependencies are and we're going to work those out. In this case we've taken these six tasks and have created a relatively simple network. Now each one of these tasks is going to have a number of time related properties. We talked about duration that's pretty easy to define. It is the amount of time that that task is going to take. By knowing the project network and knowing the duration we can then derive these other statistics as well. Let me show you first a little notation that I like to use in order to be able to keep track of all these statistics in one easy marker for drawing our project network. In this case what I like to do is I like to have the task ID at the top in the middle of this top row and then the early start on the left, the early finish on the right, the slack underneath or in the second row. Then in the bottom row I have the late start, the duration and the late finish. This is not something I invented but this is the way that I learned to diagram networks and so this is a I find it a nice way to keep all these pieces of information in one compact three by three area. So let's look at our project network again using this type of notation. So we have our various tasks and we have the duration filled in for them. From this information we can then derive all the other properties but before we do that let's talk about something that we can tell right off the bat here and that's the critical path. The critical path is the path through our network that is going to be most critical because it's going to define when our project ends and any task along that critical path if it gets delayed is in fact going to delay our project. So you can see we have two paths here through the network. So we have A, B, D and E, A, B, D and F and A, C, E and F. So one of those paths is going to be the critical path. It's the longest path through the project network. It's not necessarily the path of the most number of tasks but the one that takes the longest. Any delay of a task on a critical path is also going to delay the entire project so the project manager needs to watch this carefully. Another way to say it is the tasks that have zero slack. So if we look at our project network here we have two paths as we said before A, B, D and F and A, C, E and F. We add up the durations for those and we find that the critical path is A, B, D and F that those tasks add up to 24 let's say days 24 days is going to be now the entire length of our project. So we've been able to determine already the critical path for a project. We'll stop here and in the next video we'll look at how we derive the other time related task properties.