 And yes, it's working, it's working, okay. Excellent. Thanks everyone for coming. So we're here tonight. We're super happy to have Oleg. So Oleg, I hope I can question him properly. Selah Jeff, I hope he's correct. Yes. Yes. Okay. And Oleg is from Oracle, Oracle Labs. He's a developer advocate working on Graal VM and the Java Champion. And yes, tonight will be a Graal VM night. So first we will dig into more of an introduction for Java developers for Graal VM. Like it's very good for you if you haven't used Graal VM yet and if you want to get some general knowledge about it. And you have the best person for that because Oleg is very specialized on this topic. And we have Adrian Norton from Zenica who is the CTO of Zenica Singapore. And so he'll be actually taking a very interesting perspective. We basically will see that Graal VM is good for your performance. It's good for your memory footprints. Can we try to apply this and say that it could be good for the environments that you're gonna use less resources? So it basically means that you would save money and also have less footprint on the environment by using Graal VM. We did make sense a lot. That's the thing that Adrian is going to discuss. So thanks everyone for joining. And yeah, Oleg, you can start. Thank you very much for the introductions. I think it will be a very interesting mix of two sessions. I hope, can you see my screen? Yes. Very good, very good. So I hope we'll set up the stage with some introduction about Graal VM. And it's a very interesting project. It's a very versatile runtime. So Graal VM is a high performance virtual machine for different languages and it gives you several very unique capabilities. And since there are different languages, right? Of course, Graal VM can be used for those. So you can use Graal VM, even if you're not strictly speaking a Java developer or not using a JVM language. So if you write Node.js apps or if you're doing some Python, maybe Graal VM can help you as well. So in this session, in this first part, I'll try to concentrate on specifically what Graal VM can do for Java applications and using Java here loosely. So whenever I say Java, don't get discouraged if you're using some other JVM language. If it goes to the JVM bytecode, Graal VM, like we will call it Java here, right? So a little bit fast and loose with terminology, but it will save us time. My name is Aleksha Lyfe and as a, yeah, I work at the Oracle Labs on the Graal VM team. And Oracle Labs is a research and development facility department within Oracle, right? So the goal of Oracle Labs is to actually do science, right? So people do science, people set up the experiments, people figure out new ways to do things, and then they publish academic papers about that. And then eventually that accumulated knowledge, we try to convert that into the products, into the industrial know-how that the community as large can also use and leverage. If you have any questions, but you don't have time today, then you can find me online at GoPack by At Shlaf, almost universally. And let's just go further. This is a technical presentation, so do not make any foregoing business decisions based on the contents of this. We talk technology here. So with that out of the way, Graal VM, as I said, it's a high performance polyglot embeddable virtual machine. So there are three main qualities there. One is high performance, very self-explanatory, right? Graal VMs tries to be the fastest runtime for programs in particular languages. Of course, best in class. And of course, it's not very comparable between language to language very much, but like Graal Python tries to be the fastest Python, right? So our ways to run Java code try to be the fastest and the most efficient Java code runtime and so on for all the other languages as well. So high performance is easy. Polyglot is also, it's very confusing for people, but also kind of easy because polyglot just means that you can build systems where different components consist of like different languages. So you can have like say a machine learning piece that is implemented in Python and it would sit within the same process as your Java application, just leveraging that one particular component. And the third part is the embeddability. The Graal VM project was created from scratch in a way that it's easier to put into your Java and native applications, right? So you can take this technology and for example, if you have a large native application, like maybe database, some companies trade databases, you can put Graal VM into that and enhance your native applications with capability to run for example, JavaScript, right? Which could be a very interesting solution, right? So this is what Graal VM is in a nutshell. There are very many parts. So for Java developers, there are three main benefits that you can get from using Graal VM that I want you to know about. First, there is a just-in-time compiler that is absolutely state-of-the-art, right? It's written in Java, so it's a little bit easier to reason about for Java developers, right? And since it uses a high-level language, it's a little bit easier to maintain and evolve than maybe some other choices. So it's a state-of-the-art, it's really, really good. It produces really good machine code. It has a number of very good high-level optimizations that give Graal VM its performance boost. So this is one, the most straightforward application of Graal VM, just use it as your Java runtime with the best just-in-time compiler getting your applications faster. The second part is probably the most hyped part of Graal VM is the ahead-of-time compilation technology called native image. What it can do, it can take your application, your JVM bytecode and compile that ahead of time into the native platform binary. So what that means is that that result doesn't depend on the JVM, so it's a standalone application and then it has the performance profile of the native binary. So it will start fast because everything is pre-compiled, it will use less memory because it doesn't need to compile anything and it will run with decent performance. So that is very interesting for several use cases that are very popular lately in the Java ecosystem. So we're gonna talk about that quite a bit in this session. And the third value is the multilingual virtual machine. So you can take your Java application and teach it to run JavaScript. And not in a, I don't want to say substandard, not in a custom ad hoc way. Our JavaScript is standard compliant, right? We implement ECMAScript 2020, which is the most recent JavaScript version. So you can take your JavaScript code that you, for example, run in your node application or in your browser, and you can put into your Java application and it will run there. Or as I mentioned, you can write a component in Python and connect it with your Java application without creating like a fleet of small microservices that you would otherwise have to do. You don't have to mix all the languages. This is what like very, very often people, people immediately get scared that, oh, since it's a polyglot machine, they have to start learning Ruby and R because inevitably their application will be full with some R code just because it's possible to do. Of course not. You have to know that there is a use case for this and then ground name can offer you a solution, but you don't have to actually make your applications more complex than necessary if you don't want to. So we're gonna talk mostly about the first two and a little bit about the third, unless you have later questions and then they can elaborate on some use cases and some particular projects that tried this and have been talking about the usages. Right, so let's start with the compiler. Let's start with a quick reference first. So I just recently published an article on our team blog on medium, medium.com.slash.ground.vm and it's a quick reference. So everything that ground name can do largely, the largest capabilities are outlined there. So you can just go find ground name quick reference, download that it's a PDF, you can print it out if you want. If you're still doing that without any regard for the sustainability of such solutions, but you can also just read the article and just you will get a very good grasp of what ground name can do. So that was just a little bit of information. So Java applications, we can take Java application and on ground name, we can run them in two different ways. We can run them with the jet and that would be normally how you normally run the applications. So the context of that will be the open JDK environment. So ground name includes a compatible JDK and we currently distribute to Java 8 and Java 11 based versions. I think this is good idea currently. If there is a chat capability here somewhere in Zoom that you can use, can it please type what versions of Java you're currently using in production the most? So just numbers. And I will look at that later. It just for me to get a little bit of glimpse of what we're dealing with, right? So we have eight and 11 and you can download that. You can run Java. It will run within the context of open JDK normally just the JIT will be replaced with the Gravium JIT and your application can potentially go faster when it's done. And then there is this ahead of time compilation mode which involves a little bit more involved life cycle, right? So you build the native image first by using the native image utility and you feed your bytecode there. You feed your classes and your jar files there. That's this one part, the build part and then you actually run that application and that is a native application. So you run it by just well, running the double clicking on it. And that is the other way to run applications, Java applications on Gravium. Those two are complementary. You don't have to necessarily say like I want this or I want JIT or I want AOT. Gravium gives you a choice. So you can pick whichever better fits your needs and your say performance profile that you desire. Let's look at that, right? So the benefits of both. How it's run. So you run on the Java hotspot VM, right? Because we are in the context of the open JDK. So hotspot is the implementation for the JVM. The Gravium JIT compiler plugs into it using JVM-CI which is the Java virtual machine compiler interface which is a special interface, right? It's an interface that was added to Java 9. I think it was JEP 243 which is how you plug third party compilers to hotspot. So Gravium JIT integrates using that, well default like out of the box interface that is provided there by open JDK, right? And through those two layers we can run Java applications normally, right? The VM will do whatever the VM needs to do, right? It will find classes, it will load classes, it will run with the garbage collection that open JDK provides, right? All that, that is the Java applications. The other layers for other languages we need additional machinery there. So that is the Truffle framework in the Truffle runtimes, what is there, right? So Truffle offers you the DSL, the framework API to create interpreters for the languages. And by building an interpreter you get the full capability of the high performance virtual machine. So the Truffle framework will enable that interpreter to be efficiently compiled together with the program at runtime, so it will run fast as well. So to enable support for those other languages we just need to create Java applications which are the interpreters using a special framework but those are normal Java programs on top of Grail VM. And we have a bunch of languages there. Some of them are community implementation, some of them are actually like third party private languages that people just use. And then yes, there is the LLVM bitcode interpreter which can run native code. So Grail VM can run DOOM for example, which is not a very fascinating fact because everything can run DOOM including the modern microwaves and watches and everything but Grail VM is also within the number of things that can run DOOM, right? So this is what runs when you run the with the JIT. And the point is that we want our application. Why do we integrate the third party compiler into the OpenJTK? Isn't OpenJTK good enough? So what we want to have, we want to have a compiler that is actually sophisticated enough that you can run code that is hard, that is abstract, that it's easy for people to reason about, right? The code that you want to write but it's maybe harder for the compiler to reason about and optimize. So Chris Newland here who is definitely a performance expert, author of some performance-ranked books and he says that for his team, for code that is critical, no functional or advanced object orientation features can be used, right? You have to write DOOM code so your runtime will understand it and optimize it efficiently, right? So that of course makes us sad because as the team that does virtual machines, we think that the virtual machine should be smart enough that you can use abstractions that you want, right? Without getting to the lower levels, right? So, and we sort of achieve that thing. So if you want to get started with Graal VM, this is what you do, you download, you unpack it and you are ready to go, you put it in the path, you have your Java there, it will be Graal VM and then you can run all sorts of benchmarks and all sorts of workloads. One benchmark that I would recommend is the Renaissance which is the suite of benchmarks which is actually, it consists of the benchmarks of other projects that were specifically picked to have some interesting part about the workload. Some of them are memory intensive, some of them are CPU intensive, some of them are with like paralyzing execution, some of them was parallel memory accesses. So there was a very interesting academic paper about the Renaissance benchmark suite and how those benchmarks were picked. But you can see there, just if you just look at the names there, there was some ACCA, there was some DOTI, which is Scala. There was some MAS, like Gauss and Progressions. There was some naive bias, which is a probability theory. There was some Neo4j analytics, Neo4j is of course a dig graph database that is a very memory intensive workload. There were some reactor and RX-crabble so it's some reactive extensions in play, right? The libraries that you use in your code are represented in there. And GraalVM achieves really, really good results on those almost universally being faster than OpenJDK of the same version. But that is not particularly the point. GraalVM is faster, usually is faster, right? And the point is we also run a ton of benchmarks that we know it. Now for you to know it, that's a different question, right? The best way for you to know it is to actually run it on your code, right? So the getting started is very simple. You just need to unpack it and run it and try it on your code and see whether this is faster or not. Because however, if we run just benchmarks and not the real life code, right? Then we get into this point where we optimize for those particular benchmarks and it becomes a game. It's like overfitting the machine learning algorithm. We show really good numbers on that benchmark, but when we see the real world code, the performance is not up to the expectations. So that's why I like Renaissance particularly because it uses frameworks and libraries that we are currently using, that are currently being developed, right? This is not the benchmark that was created 15 years ago when we wrote Java very differently, right? So, but again, right? You should think about benchmarks. You should try on your code and you should extrapolate with care. One thing that definitely speaks for Gravium is that for example, it improves very rapidly. So the last year, right? So 19.3 was released in, well, 2019 and 20.3 was released a year later in 2020. And over a large range of benchmarks, the couple, specGVM, Renaissance and ScalaDecapa, the newer versions of Gravium got approximately 6% faster than the older ones, right? And that is not just faster because the old benchmark like baseline was lousy, right? It's very easy to show relative improvement when you start from the low point, right? But when you start from the best of the best and then you add 6% of improvement, that says a lot, right? And the progress there is not stopping, right? So definitely this is something if you would like to have a faster runtime for your Java applications, this is something that you want to look at, right? So this concludes sort of part about the JIT, the introduction about the JIT because it's sort of simple and very transparent for the user. You download, you unpack, you run it, it's faster. If it's not faster, Sabitan issue, we will make it faster or we will try to make it faster, right? And so it's very simple to understand the use, right? ATT is a little bit more involved and it starts from the understanding what we mean when we talk about performance. What does it mean to have better performance, specifically in the context of the head of time compiled application? So apparently when people talk about performance what means my application is faster or my language or my runtime is faster. They mean different things. Sometimes they mean the peak throughput and the bestest latencies that we can have, right? This is what we normally optimize for when we run our Java applications. This is what JVMs, Java Virtual Machines have optimized for 25 years now, right? We run our application, it runs for hours, it warms up and then it's really, really fast and then we measure it. That is the peak throughput, right? The max latency is we run our workload and the slowest responses are the maximum latency. So the faster are the slowest responses, the better is the general user experience because there are no requests which are stalling because of the latency. And there are the different factors, right? There is the quality of the JIT code, JIT code, sorry, the quality of the GC and the runtime in general but that is a different dimension of performance, right? And sometimes you want not to have latencies at all, right? So if then you would probably go with like postless, postless garbage collection and then you don't maybe care about the throughput that much. So you don't care how many users you serve using the particular set of hardware. But then there are also other dimensions. Sometimes people say fast when they mean that the application is starting fast and it's ready to go as soon as possible, right? That there is no long startup and warm up phase and they say, this is what I mean performance, right? Sometimes people say, I want to put as many applications, I want to scale my application in the constrained environment and I want to assign the smaller chunks of memory to every particular application because this way I can utilize my hardware to the best because I will have the smaller building blocks, right? The smaller containers. Sometimes we will even say like, oh, performance is packaging, right? If your application is too big, then it's slow because it will be slow in certain use cases, right? So there are different dimensions. The good thing is that the JIT part when you run with a JIT, you normally would get good results at the peak throughput and at good latency, right? You will not get the good result on the startup speed because the JIT needs to warm up and actually JIT stuff, right? It actually has to do work at runtime so it cannot be fast from the very beginning. The same with the memory footprint. The JIT needs to be work for that. It needs to allocate memory for itself to do the graphs of the application that you're running, right, to compile that code. It needs to use memory for itself. So the memory usage will be always higher. The larger your application is, the more code needs to be compiled, the higher this overhead of the JIT will be. The head of time compiled application, typically they feature different trade-offs there, right? So the startup speed will be better. Everything is pre-compiled. The memory usage will be lower because, so better because there is no JIT, nothing needs to be compiled. The application just needs to do your business logic to run whatever you need to do. The packaging will probably be smaller because you don't need to run the runtime. So you just, you can ship literally your application. So those two modes kind of have those trade-off between what they mean when they say I'm fast. And it's very interesting because, sorry, the startup speed memory footprint and packaging, a very popular criteria for performance in the cloud workloads, right? So when we run our software in the cloud, we usually want better startup speed, better memory management, lower footprint, small packaging because in the cloud, we don't want to scale our application manually. Something else will scale it. So we never know when we need more instances or less instances. So having like this one Java process that is taken care of is maybe not ideal for the cloud. So this is where it's very nice that Gravium gives you options to run this way or that way. So you can just pick and choose whichever you want. So you like, Gravium doesn't compete with solutions that offer JIT because it offers native image, right? Because it offers AOT because it competes because it offers a better JIT and the AOT is just a chair and top, right? So this is how you run and this is the second part that you can put that alternatively, you can run the native image of your application and that will be the platform binary. How it works is that your bytecode is analyzed under the closed world assumption. This is important, right? This is important because this outlines the trade-off and you need to be aware of that because otherwise you will start trying to do that and you will get discouraged and you will come to our channels with questions and I will be sad because I would understand that I failed. So this is what we need to understand. The closed world assumption means that all the bytecode that will ever be executed is known in advance when we build our application, right? So there is no random loading of new classes at runtime. Everything is known in the beginning, which is very typical actually how we build software. We package them into the immutable Docker containers anyway, there is no additional classes that will just come out of nowhere. So seeing all the bytecodes allows us to have very aggressive optimizations. For example, we can eliminate some null checks if we know that their items are like objects and non-nulls or if we know the class hierarchy never changes, we can maybe inline some direct method calls easier. We can bypass the class loader or something at runtime because we saw all the bytecode so we can compile it ahead of time, like not even ahead of time, but like we can compile it before, right? So the trade of there is that dynamic parts require some configuration at runtime, at the build time. And dynamic parts are inherently dynamic, like reflection or generating proxies at runtime. So you need to provide the configuration for that. You don't have to do that manually. There is a Java agent that can provide that configuration for you, but you need to provide the configuration because the static analysis that determines which classes and methods to include in the final application cannot predict your random reflection usages, right? So that is the trade-off. Good performance for AOT versus configuration that needs to be provided at build time. And at the build time, this is what happens, right? All your application, your libraries, the JDK runtime classes and the components for the runtime from the Braillean project, they all get initialized. They're all written in Java. So it's all Java bytecode. So they all looked upon in the same way. So your application is analyzed, your application is initialized, the classes are loaded, then everything is snapshotted, right? Both the code and the data on the heap. And then it would put in the output executable, both code and data become parts of that native executable, right? And that native executable includes a runtime component. So this includes a GC, for example, because the application wants to run as if memory is infinite. So it will still run the same way with the GC in the native, in the native binary. So you will not get the performance of Rust or a performance of hand-tuned C++, but you will get a very different performance profile compared to running Java applications with the Jet. And that performance profile is very simple, right? When we look at the startup of application, we will use much less memory. And you can see on the left, this is an example of a micro-not application serving a couple of requests. So on the left, we have the ahead-of-time compiled application. This is the same application. And on the right, we have the Jet. So the left one uses a little bit more than 30 megabytes of memory, right? And it uses just a little bit of CPU only when we serve requests. So the request I served was a one-second pause. You can see there are some tiny, tiny splashes of red here on every second when we just serve the request. So in contrast, when we run with Jet, the JVM starts and it does a lot of work, right? It needs the initialization, it needs to the class loading, the memory grows up higher. Then the first request hits here at around when the JVM is ready, right? And then when the request hits, you start to compile more code and you start to initialize more code. This is just the nature of how the Java process operates. It's not bad, but it's just, it's what it is, right? So it's in a striking contrast with the ahead-of-time compiled way, right? So what the ahead-of-time compiled mode does, how do you get used of that? It's very simple. You can pick a choose a number of frameworks which support that. There was Helidon, there was Micronaut, there is Quarkus. Spring works on the Spring Native Initiative to make Spring applications working with Gralium Native Image. For common line applications, you can use PicoCLI, which is an excellent library, excellent library for creating common line applications and then compiling them as Gralium Native Image afterwards. And the best part is that the benefits that come from using Native Image, they by far outweigh the differences between the particular frameworks, right? So the startup speed, for example, with the Native Image will get to the milliseconds, right? So it will get 20, 40, 70 milliseconds, which is 10x faster than normally, or maybe like 50x faster than normally the application will start. And that is without any regard, without a lot of regard what application framework you're using, right? So there are some differences there, but then again, maybe different between 23 milliseconds and 30 milliseconds startup are not particularly that important. The same with the memory footprint, it gets much, much lower than normally with the application of Native Image and the differences between the frameworks become much more negligible, right? So this is it. This is what the head of time compilation can do for you, right? It can provide you with a very nice performance for the cloud deployments specifically. Common line applications are very nicely mapped on the benefits that Native Image provides being standalone, being fast at the startup, being low at memory usage. So this is what Grail VM can do for Java applications running with this superb JIT and running as the native executable, right? There are many components to the Grail VM. Some of them are production ready. Some of them are experimental. So we waste run Java code on our production ready. So both Native Image and the JIT are production ready. Companies and teams are using that. People are happy. Everything is good there. Some other languages are experimental. So that means that some things might not work out of the box or require tinkering. Some of very new projects, like the Python, for example, or there was a language called GRQDA, which is the language to access GPU and NVIDIA GPUs done in collaboration with NVIDIA. Right. If you want to address peak throughput and improve the maximum latency, like those areas where a native image, the ahead of time compile thing, wasn't as good as the JIT, there were ways to do that. Specifically, if you use Grail VM Enterprise Edition, which is a product by Oracle, you can use the G1GC garage collector for improving latencies. You can also use profile guide optimizations to capture the profile of your workload and generate better machine code for that. So if you want to do that, I encourage you to use, to look at the actual using Grail VM Enterprise Edition and how those things work. But you don't have to do that. And then the Grail VM Community Edition will provide you with performance benefits as well. Right. So Twitter is using Grail VM Compiler in production, running their Scala microservices. Oracle Cloud Infrastructure migrated some of their Java workloads. This was actually, actually this was quite some time ago now, more than a year ago, and they saw good benefits, less time spent in garbage collection, better performance, the migration without problems, which is very good. As I mentioned, yes, NVIDIA and the GRQDA language. It's a very interesting experimental way to maybe access GPU and so on. And of course, if you want support, if you want the absolutely best technologies that Grail VM can provide you, you want to look into maybe options, how to get Oracle Grail VM Enterprise Edition. It's functionally the same. So it will run the same programs that the open source bits or that Grail VM Community Edition can do. But it will provide you with higher performance and some additional optimizations besides the support. So that's that. Right? You can use Grail VM for your application and I encourage you to look at all the resources that we have, the websites, the team blog, the Slack community that we have. And if you try Grail VM, I hope it works for you out of the box as it does for many, many teams and projects. But yeah, come talk to us. If it works not as great as you would like it to work, come talk to us, obviously. If it works as great as you expected, come talk to us as well, because that is absolutely the best feedback that the team can get is that people try and use the products and they're happy in that. So that is something we don't have enough in the industry, I feel, just spreading the positive message about not particularly Grail VM, but just in general about the projects that we use here and there. When something works normally, it's a lot of invisible work has been put into that. So any signs of appreciation are welcome. Yeah, I got a little bit philosophical here, but this is sort of the end of what I wanted to share with you tonight. Yeah, Grail VM can do different things for you, right? I hope I was still sharing my screen this whole time. That's very good. And should we ask if anybody has any questions? Can we have time for this? Yeah. Do you guys have any questions for Oleg? You can type or you can... What are you thinking about? Don't be shy. You can ask anything. Right? This is actually, while you're thinking about the questions, I can share one data point about asking questions. You know how there are different cultures, how people learn and how people communicate in different settings? So Estonia is very close to Russia, right? So I'm on the border between two cultures. And in the European culture, asking questions is not very often something that people do eagerly, right? And I think the sentiment there is that, oh, I didn't understand something. Thus, I'm stupid, right? And everyone else is smart and they understood everything. So I will just distract everyone by asking my question, right? And people don't ask questions or don't like asking questions that much. In the Russian tradition in the culture, it's absolutely the opposite. When you ask a question, that means that you understood that you didn't understand something. And thus, you were smarter than everyone else who didn't understand that they didn't understand because they didn't get the question, right? So questions are absolutely excellent, right? And we have a question from Salva. Is there a more information regarding optimizations done in Oracle Rall BM? And the question is, yeah, absolutely. There is more information about that if you are asking particularly about the Oracle Rall BM Enterprise Edition, which is a proprietary product, then yes, there are some patented optimizations in there. And there are some, there are of course information about what those particular things do. I'm not sure how the best you can learn that information, but if you are asking about the product, I will be absolutely happy to connect you with our product managers. Or if you want to go as far as that, I can connect you with the salespeople as well. If you're asking about Gravium compiler in general, right? And optimizations, how the compiler works, then there is information as well. And I also have a session that I can do potentially, maybe some other time, or maybe I can find some other conference venue about the compiler and what makes the compiler so good, right? So in a nutshell, if I just summarize that in like two minutes, Gravium compiler is the optimization works on a graph similar to what C2 does, right? But it's a little bit more sophisticated, maybe because it's just newer, right? So the second implementation is typically smarter and better just because you have the experience of the first one, but also there is quite a bit of work, academic work done into that. And then Gravium compiler has excellent high level optimizations. So our inlining, our polymorphic inlining, our escape analysis and data flow analysis are absolutely top notch. So even if the smaller lower level optimizations are not that fine-tuned, Gravium gets better performance just because the high level bigger optimizations that are really, really good, right? So this is the very, and I can also send a link, for example, I'll find a link later and somehow share the information, some blog posts about the particular optimizations and some code examples and snippets about the compiler, right? So if you read the assembly, that would be an interesting read for you. If you don't read the assembly, like I don't read the assembly, I just stare at it, that it will still be an interesting read, but maybe a little bit less detailed, right? We have another question from Andrew. Is migration from opportunity to Gravium supposed to be a drop in replacement or there will be additional steps needed? Yes, it's supposed to be a drop in replacement. So Gravium binary, the Gravium distribution, right? Contains a compatible JDK, which means that you put the Java on the path and you run the Java and it runs the same Java applications that your other JDKs can run, right? That's the whole point of the standardization and compatibility. There could be, there are like one particular component, subcomponent of the VM that needs to be aware of the JIT and that is the garbage collection, right? So a garbage collection needs to, like if the other will run, the JIT needs to be aware of the garbage collection because the garbage collection can, when it runs, it can impose certain scheme of how the objects get accessed. So sometimes you need to read barriers or write barriers. Sometimes your objects are migrated. So you need to pad them with some, like for example, forwarding pointer or something, right? So the garbage collection can change how your objects are accessed. So it can change what can be done within the code. So the JIT needs to know about GC because when it compiles the code, like it better worked the same way with the GC as previously, right? So there was no point in compiling code while breaking it at the same time. So those two need to work in tandem. That means that for integration with the additional GCs, you need the integration in the Gravian compiler as well. So currently we support the parallel GC, G1 GC. And I think I've heard something about CMS. So those could run if you use some newer GCs, then you will not be able to use either the Gravian compiler or that particular GC implementation. So in that sense, the application will still run, but that is something to be aware of. Right. So I hope that answers, right? How about migrating existing applications on Oracle JK to Gravian? This is literally the same thing. So Oracle JDK is the distribution of open JDK, right? So not on eight, right? But like on 11. When eight, there are some differences between open JDK and Oracle JDK, but in that sense, if you use an Oracle JDK, then I would encourage you to look at the Oracle Gravian Enterprise Edition, which builds on top of Oracle JDK, right? And then the migration will be absolutely trivial the same way you just changed the pass and you're good to go. And also, Puneet, if anyone is asking, have you been able to run Spring with apps in Gravian? So I hope, I try to make it absolutely clear that Gravian can give you different choices how to run the application, right? All applications run in digit mode, right? They're just normal JVM process, everything will run, you can run Spring with, I like that in Gravian. If you're talking specifically about building the native image out of that, I would encourage you to look at the project called Spring Native and it's a very interesting project. What it does, it gives you the configuration necessary for running Spring applications as the Gravian native images, right? So it's available on GitHub, you can find some blog posts, you can find some sessions by the Spring team, committers and contributors about how to run Spring applications as native images. There are a lot of samples that work out of the box, a lot of technologies are supported. The broader Spring ecosystem might see some challenges. The main part there is you need to understand what the Gravian native image is doing and then you can run mostly all applications, right? But it requires you to understand what native image is doing, what your JDK is doing, what your application is doing, what your dependencies are doing. All the code that gets into the final result, you need to sort of understand what it is doing, which some could argue that this actually like maybe a good thing to understand what the application is doing, but very often we are just kind of drowning in complexity and rely on just proven battle-tested solutions that though this works and even if I don't understand how it works, it sort of works somehow, right? So then there could be some obstacles because some parts you need to, maybe dynamic parts you need to configure and so on, right? But yeah, certainly look at those presentations, look at that project for Spring applications. And well, yeah, right. I hope that's it because it took a little bit a few minutes longer than I expected. So I'm sorry for that, but I hope it was interesting. Yeah, thanks a lot. I mean, that was very interesting. Yeah, thanks for your time and thanks for your talk. I think now we can move to Adrian, if you're already Adrian. Yeah, thank you, Oleg, if you can ensure your screen. Yeah, absolutely. Great. Just for like a few seconds during Adrian's setup, just a small sketching that you will receive everyone about your lecture. Oh my God, this is absolutely brilliant. This is spectacular. So... Oh, thank you so much. You will receive it and all the participants too. So now we will go to Adrian. So please, Michael. Yeah, actually, I already presented Adrian who is the CTO of Zinica Singapore and who will be talking about, okay, since Gravium is bringing more performance, it's one of footprints, does it mean that we can actually consume less resources and we protect the environment? So that's the perspective we're going to take with Adrian's talk. All right. See you, Adrian. Thank you. Thank you, Michael. And thanks, Oleg. It was very interesting and actually it's going to support what I will be presenting. So hi, everyone. I'm Adrian. So I'm not sure if you can see my face over there. Anyway, the idea behind GALVM, as you've seen, it's an engineering tool. So Oleg has presented you a lot of different features and very exciting promises about the product itself. And I wanted to approach it slightly differently and give you maybe an architect's insight on how maybe this technology has potential to be used in a better way. So let's start and let's explore a bit. And first let's start with the name itself, Grav. So we're going to explore it. We have really found the Grav, meaning did we finally found the silver bullet for all our issues? We're gonna explore that a bit and put that just in your moment. So if we start with Grav VM, it's a set of features. We've seen that with Oleg. It's polyglot, it's efficient. So you got the JIT compiler, you got the AOT compiler. It's extendable, what we have not really deep-dived in is we can add a lot of different extensions, plugins and all. And if you look at the native image feature, the one that you've seen marketed everywhere, it's actually a plugin. So the fact that we have a new developer's kit that is so extendable with a lot of different well thought features, it's actually pretty exciting for the future. So maybe we've found something that can last as well, a technology that can make a big impact when it's released. So as of now, and then maybe we can also use in the future. All right, so let's explore a bit further now because this talk is also about renit and sustainability. So when we talk about sustainability, we usually talk about the three keys. And usually when you work on projects, when you work on technology, you worry about people. So the persons that you serve and the person that develop the solutions, and you also worry about making profit, right? That's usually what we do in the industry. When you find a balance between these two, you can find fair solutions. But that's not enough for sustainability. When we want sustainability, usually we will aim for the three keys and the third one is actually the planet. So that's why you get a lot of talks about environment, about ecology in general, to be included in the solutions that we designed as architects, as engineers for IT products. When you add the planet, well, Victor, usually when you combine it with people oriented solutions and that also range in the build mode, the pace of the developers, you talk about livable approaches, right? It's good for the planet, it's good for the people, but you don't make a living out of it. When you combine the planet and the profit, you have viable options. It's not really directed towards people. Well, you might think of some social applications as well, social media applications about that. When making profit, it can be sustainable in the way for the planet, but it's not really directed to the people. It can be a bit too introsy, for example. I can use them instead of serving them. But when you have all three, that's actually when you can find a sustainable product. When you have a good balance between making money, having the necessary resources and never burn them, and when you address people needs, when you include them in the process of, when the build process and in the usage, that's where you can find a sustainable approach. So now the idea is there a relationship between these two. Okay, we're going to explore that. We're going to check, because that's a question that we have. We don't have an answer yet. We're going to check if well VM is actually aligned and can be a good tool to build sustainable products. Before we do that, what I propose is, and bear with me a moment on that, sorry, is that we have a quick focus, right? A quick focus on what it means for the planet. What is the impact? Why do we try to build sustainable products also for the planet? I will give you just some numbers, bear with me for like five minutes in order to define that. All right, so we're going to talk about three things. It's going to be quite awesome. Greenhouse gases, the emissions of CO2 and other gases like Newton. We're going to talk about recycling in information technologies, in technology in general. And the last one, we're going to talk about obsolescence, right? So let's start with greenhouse gases, just some numbers for you to know what we're talking about. There has been a real study back then in 2013. It was, you know, conducted by CET and Bell. And what they found out by examining all the servers that were running, not supporting the internet and all, found out that the greenhouse gases emission from their servers alone was actually 2% of the global CO2 emission. And back then, they only looked at CO2. And back then, they have mainly servers as well. And also back then, it was already the equivalent of the aviation industry. Now we're in 2020. We have new studies as well, conducted also by Bell, but you have to see that in 2020, we have 70 million servers against 34 billion devices, your mobile devices, your tablets, all these devices, you must have multiple screens at home as well. And maybe you have a 4K TV vision as well. Smart TVs, right? 34 billion devices. The impact of this is huge. Today, we think that actually we're more towards 3% of the global emission. And if we include methane and all the greenhouse gases, not just CO2, it's actually even higher. When we look at that, the part of the emission from the servers is only 35% nowadays. When we look at 2013, already when we talked just about servers, it was already 2% of the global emission today. The global emission of greenhouse gases that is from the servers is only 35% of the total. The devices, they take 62% and 35% of the 62% comes from manufacturing the devices. So we already see that we may have an issue by renewing our devices very frequently. So one of the main basic of eco design, when you are designing applications that are sustainable, is actually also to include as much as possible the legacy devices. If you need a new device, the latest train, in order to run your application to products, then you are not really helping in that way. That's something that we have to be aware about, aware of. So it's fine, it's a choice. You may have a good, I would explain to you the good excuse as well for that, but I'm just trying to raise awareness on that aspect. So let's move on to recycling now, some numbers in order to know what we're talking about as well. Today, only 20% of the e-waste, so basically your devices, when you throw them in the trash bin, only 20% of the components are recycled. 80% of them, they're either burned or they're just left in the niner or somewhere. But out of these 20%, what is even worse is that we found out with some studies and with deep investigation that 70% of these 20% of the e-waste are supposed to be recycled because they enter the recycling process, 70% are trafficked, meaning that 70% of the people and the organizations handling the recycling of your IT products and your IT devices, they are from the mafia. They are from illegal organizations. So by doing that, you are actually making the mafia organization sustainable. You are working towards sustainability in a way, but maybe not the ones that you are looking at, right? So that's kind of the crisis these days. It's pretty cool to actually know what they're going to do when you give them your devices in order to be recycled. Sometimes they're just gonna dump it if you're lucky or sometimes they're gonna make money out of it. So they're going to go even more poverty. Now let's look at obsolescence. When you build an IT product, it's not for free. Of course, you have to pay money, but you have to pay more than that. You have to pay for the time of the people. And even beyond that, when you run your applications and when you build them, you will need these devices, these hardwares anyway, either the developer's laptops or the newest ones, right? Every developer wants a new laptop in a way. You also need the little servers. You need a lot of different machines and all and sometimes not really optimized. In that aspect, you need a lot of different minerals to build these devices. And we have a limited resource on earth. Second, it takes a lot of water. You need a lot of water in order to manufacture these hardware and you need also a lot of energy. When we look at all this, what we would like to optimize are different things. We would like to optimize runtime. So making it more efficient, spend less time on compilation, spend less time also on waiting for the application to start, optimize the CPU, the GPU utilization. We've seen that also a little bit. We're gonna go back to ground in a minute, don't worry. We also want to look at the device compatibility because you've seen how much waste we generate, right? By changing our devices. So we want to make the devices last longer. Based on all this, we also want to recycle other things. And I haven't talked about it, but we want to recycle skills. That's why I talk about languages. Today we have a big community with Java and you've seen maybe with the latest trends that Java sometimes, well, is still pretty steady in terms of popularity, but developers are interested in the new things, right? In Python and Scala, in a lot of different languages. And it's normal because we like change as well. In that aspect though, we are not recycling competency as efficiently as we maybe we should in order to have sustainable ways of developing products. And let's look at how maybe Gravian can answer that. All right, I'm finished with that particular, you know, a catalytic stick part. Hopefully we can be a bit more optimistic now. Oh, one more thing. How do you assess all these things? And in fact of your technology productions, usually we use LCS for life cycle assessments. Of course the LCS, since we are going to talk about certain attributes and certain properties of our build process and our run time process, they're only so good for comparisons. When you use the same elements of comparisons, then it's good you can compare if when you have built a product and when you run it, it's actually better or not compared to another product with the same assessment. You cannot use an LCS to compare very different products, upland arranges, you can't do that, right? So once you ask, once you stick with some elements of comparison, you should reuse them with the same kind of products and see if you can improve your processes. That's how usually you tend to, you know, optimize your usage of abiotic resources and also not have not so much points. All right. Let's go back there. So we're going to have a quick focus on eco design, right? Beyond engineering, engineering is the etymology of it is actually more towards inception. People are inventing stuff, right? It's all about creation, engineering. When we talk about architecture and design, architecture is from the Greek word that means a deep builder. And in that aspect, we are supposed to move much further than the engineers, right, as architects. Our engineers can be architects as well. It's just a role that depends on the time. But when you have an architecture posture, usually you will try to work on the design itself and if your product can last, it's scalable and goes with an ROI. And when we talk about ROI, it's the return of investment usually, but then I will propose you another definition. If we can reuse, if we can optimize, and if we can innovate, right? These are the three things that I would propose. And let's look at GraphVM from this angle. Let's look at GraphVM and see if we can reuse stuff, if it's going to help us on optimization and if it will help us on innovation as well. All right, let's start with reusing the Java community, right? GraphVM, of course, it's probably a lot of course, now it's inclusive, it's much more inclusive. You can run a bunch of different new languages because of trouble and because of LLVM as well. It's pretty exciting. But the core of it is actually the JVM, right? And the JVM itself and how to manipulate how to use Java, the professors in language and the historical one, you have a whole community around it. You can reuse the skillset of many people, of the whole community. You have 20 plus years of experience, it's a mature technology, it's a mature community. It's very helpful, you've got a lot of developers, you can reuse all these and you can already share. You got practices around it. You're not left alone, we have solved so many problems in Java that today, when you have a new issue, you go to Stack Overflow, pretty sure someone has already tackled it, right? So about reusing in equal design, you don't spend too much time finding out how to solve a problem, so you're optimizing your development with that. So it's good to reuse. Also, you are reusing all the 20 years of experience on how to build very performance virtual machines. But it's why today, when Olex says instead of the art, JVM, well then what they offer with the JVT compiler, is right, it's born out of all the experiences and all the also expert advice of the people and that's the final product that you have today. When we move on to optimization, we talk about things like memory footprint and you've seen that now we have the opportunity to reduce it. We talk about throughput as well and now we are given options as well. We can either go with native images or we can just use the JVT because we need computing power, even more than that, we need to have a hand on that. If we want to delegate it to a third party system with native images to run serverless applications in the cloud, for example, in order for the cloud to scale our own applications, we can do that, but if we want to handle the throughput internally, we have garbage collector optimizations on our side. We have many things that we can optimize out of today. So it's very good for the throughput as well. For the package size, now we have an opportunity to also control it with native images, we've seen that, we've seen the differences of the sizes and also with the module of VM, right? That's something that we would like in the JVT ecosystem. For innovation now, because that's, you can't just have a reusable and optimization. If you stick to that, you're going to be very conservative. And the problem with being conservative is that you don't survive much because times are changing. So in order to build sustainable products, in order to build a sustainable development environment, you also need a base for innovation. So let's look at that as well. What I like about some innovation and tools for innovation is the capability of flexibility. When we tackle a new problem and when we want to find a solution, we are going to ask ourselves a lot of questions, right? And when we are going to engineer a product, usually we start with these questions. We want to know whether we have to spread the technologies we have to look at different technology in order to solve different issues or we want to centralize everything. For example, if you use Kafka, maybe some of you already use it, you want to understand whether you want to use Kafka as a backbone for your product, or do you want to use Kafka as a modular component just for messaging, right? Do you want to spread or do you want to centralize? Then the second thing is, do you want to have more possibilities or do you want to have better options? When you start with a product, you have to see if what you are interested in are the options that the product proposes you or if they propose you to do things in a better way. Sometimes you can have both. Sometimes you can have neither, right? So that's something you have to look at. Then there's another part is about tell the system-plated. Do you want your tool to be very flexible and you can do whatever you want with that or do you want it to be very opinionated and give you the templates to be faster? So all of these are the triggers for innovations because you will have different paths and you will be able to grow differently. And that's how you innovate. It's by finding new paths. It's by figuring out that there is no silver bullet. So maybe there is no ground in VM, but maybe ground VM helps you innovate. There is this thing called a ground VM as a platform and Oleg hasn't really pushed further about this thing, but you'll see that with Truffle, for example, you can create your own language that can run on the VM. With LLVM, you can build the tons of language that are also built on the LLVM and you can just run them on ground VM as well. So you can use ground VM as a development platform for R&D for new ways of writing applications, which is pretty exciting. But with ground VM overall, sorry, you have choices. You have choices like AOT versus GIT. You have choices like JDM versus LLVM or Truffle. Java or Truffle are base languages. Even all the first class citizens like address return all, and you have extendability. LLVM is a platform. It's not just the native image compilation and optimization and the fancy stuff that's about how it's working with us. It's much more than that. It gives you a lot of options as inputs, meaning that you can decide your languages, you can decide how you want to develop your products and you can now also decide how you want to run them. So it gives you plenty of options during the build phase and other options during the runtime phase, which is pretty great for a great, we don't have that much with the other developers environment. Well, some of them try to. I would, I would, I would just want to do like, you know, it's not like any data where you want to file. It's more like a monitor. All right. Sorry for that. So now let's move on a bit. We've seen stuff about the TPPs, about sustainable products, so what we will need to design them from an architecture standpoint. We've seen why it can be important for the planet to worry about ecology in general to build sustainable products because we have limited resources and also it impacts the planet, what we are building in technology. And we've talked a bit about eco design and how well the MQVA to that. And now we are going to move to the last part. The last part is how a GDT can help sustainability. And I'm still going to talk about GraVM, right? But from a certain standpoint, from the Agile system. Let's talk about the GDT first. Usually when we develop products, we have that, right? We have a scope. We have some time. We need to develop something. And we have an initial target and we are going to evaluate at the time it takes us to go there. So that's how we define speed. The first evaluation of the real city of your development. The base, the core of Agile, it's all about change management, right? It's all about course correction. So instead of focusing on your target, instead of focusing on your initial speed, what you are going to focus on is how fast, how reactive you can be when you change targets. How fast can you change the course? That's Agility. If you don't need to know by heart the manifesto, you don't need to go even further. If you haven't understood this, you haven't understood the principle of Agile. Now, how can it help? How can GraVM, you know, help in that? It can help in sustainability because you will always adjust. That's the first thing. Once you measure and you will have some feedback on your application, consuming that much resource, running on this kind of device, when you have all this feedback and when you work on it, when you readjust the target, Agility is going to help you. Now GraVM, it provides a good platform in order to have Agile development because it's flexible. Since you can delay some choices on conception and engineering with GraVM, it helps you redirecting, right? Redirecting the choices, doing some course correction after the initial inception phase. So, GraVM gives you flexibility on packaging. You can do native packaging, you can use a J2. You can use different ways to package and it's extendable, so maybe tomorrow you'll have all the plugins coming in that you could install in your JDK and use afterwards. You can provide you options for deployment. Now with it, for a long time, we wanted to use Java technologies for serverless. We can use it already in the Cloud Java, right? We can use it on a computing machine, no? It's fairly good, but we need to get the VM ops and we have to worry about them. We have to worry about balancing ourselves and all and going for full serverless architecture, just write our functions in Java was not really helpful, it was proposed, but the time to start the function could take one to two seconds because of the old VMs. Now we are beyond that, so we have multiple options. Which is pretty interesting for architects. And also, for usages, we can look at this further. Oleg has not really ninger from that, but if you heard what he said at the beginning of the talk and maybe you caught it, you can run Grad VM directly embedded in databases. You can run Grad VM as native applications on your phones, on your mobile, if you're in an Linux environment. You can run this everywhere basically, so you can really fine tune it to have multiple deployment options that you didn't have back then because not every device could run a JVM. The fact that now the JVM is optimized is pretty great when we need CPU and memory-intensive kind of work, a lot of computing throughput, right? But with this native image, we have the possibility to look at beyond the usages that we have today with Java. And we can do that without thinking about it at the beginning of all the developments. So what's next? And is Grad VM helpful? I would say yes. I think Grad VM helps a lot for sustainability, for building sustainable product because it gives you all these changes, all these flexibility. And it's very promising because as you've seen, it's still creating the creation phase. You have Oracle Labs. You have the community very interested in the project. You have different ways of using it with MicroNote, with focus as well. And you have all these efforts in order to build many more tools around it. I'm pretty sure it's still not mature yet, but in the future, it will help you and it's a good foundation solution platform in order to adopt agile developments, so a technical agility, and to build sustainable products because when you are going to build it, you are going to reuse the talents, the skills of the people, you are going to create new ways of deploying these two devices in order to help people that may not have the latest problems, that cannot run the latest JVM at all, that do not have that much power in their hand. You are going to have many more options and I think that's a good preparation for the future. So yeah, that's about it. I do believe that, well, the VM can be a good match and can give us hope. It can make us optimistic about being a good tool for the future. Thank you. And do you have any questions? Just looking at the questions now. Adrienne, I think there are a few questions about what tool you're using for your presentations because it looks pretty awesome. Oh, that's concept. Yeah. Okay. I think it was written already. And yes, it's on the iPad. All right. And that's about it. Yeah. Thanks a lot that you guys was very interesting. Thanks for connecting the dots on the environment and grow VM. Jerome, do we have anything else before closing? I think we cannot hear you. Let me unmute myself. Yes. I was trying to finish the recording from my dream. Unfortunately, not enough quick. So as I currently have a technical issue for the music and everything, we will leave you in silence. And if you have any question now to both Oleg and Adrienne, feel free to type it. If you find this meetup completely boring, feel free to type it also in the chat. Or if you liked it, feel free to type it in the chat too. Feel free to interact with us. And I will try to provide more recording to all the talk we will have furthermore. And yes, I am using also concept. Adrienne, did you make your own drawings? Or did Jerome do it for you? No, he's the artist. So you can speak out, Adrienne. So Jerome gave me the tool, as you can imagine, because we were together a lot. But I myself did all the drawings. That's cool. It's one of the concept of agility. Just provide tool. People will find a way to use it. And there is a need for change too, with presentation. That's why. So, thank you, Punit, you're a lovely person. I love you. Love you too, bro. Happy New Year to all of you. Yeah, happy New Year. Thank you, everyone. Yeah, thanks, Adrienne. And Oleg, I understand you have a big milestone today, right? About GralVM, or? Yeah, apparently today is the release date for GralVM 21.0, the first release of this year. That's cool. You guys have any kind of audience out there? No, no, mostly the... Oh, to be honest, yes, right? So it's a little bit awkward time zone for people in Singapore. But I invite you all to a live stream of what they call the unboxing stream for GralVM 21.0, which will be like evening European time. So it's sort of weird for people more into Asia. More into Asia. It will be 7 p.m. central European time. It will be live stream on Twitch, twitch.com slash oracle underscore labs. You can find, like if you Google my Twitter account, you can find the links, that's the easiest. Yeah, and we're gonna unbox that GralVM and look at the changes and maybe see some demos and there'll be some guests. And this is the new thing that I would try to incorporate into our community this year, right? And this is the first one. So I'm a little bit nervous about how it will go, but I assume it will be very casual. So hopefully it'll be fun. And as in every time, the release is very interesting time because there are so many components, right? And they all move forward at their own pace. It's a little bit stressful because we only have sort of one voice as the whole team. And of course, this is my subjective opinion, right? And everything, but it's very important not to forget some projects, right? So there's obviously a lot of interest and a lot of hype and a lot of ice on the native image, for example, right? And somewhat on the compiler because the compiler powers everything, but even the projects that are maybe not as popularized, they're very important, right? So for example, we have the Growl, Vasem, the WebAssembly interpreter support, right? And it doesn't, like we don't talk about it enough or like a lot, right? But it's important not to forget about those, the existence of those or the tooling, for example, right? This is what Adrian talked about as well, right? So that there's the ecosystem of surrounding like adjacent projects near the actual like runtime project, right? So the tooling is a very important part of Growl VM. This is tooling is actually what I think tooling is what makes it an ecosystem truly, right? So the languages get support for development tooling. There are things around that, which is always, they personally, they surprised me the most because they come up with new cool things to do every release, even though like it seems like, what new can be there in the tooling section, right? But yeah, there are projects that are like experimentation and what you very correctly emphasized. I think Adrian is, Growl VM is not just the runtime that he can use right now. Of course you can, right? You can, then it might provide benefits. It might provide like more benefits or it might be like interesting for you as a, like as a product, as a business to use it or not. Like there's all about the trade-offs, but it also provides the test bet for the future projects and exploration, which very often is interesting. Excellent, so yeah, best of luck for this today. I'm sure it'll be fine. And yeah, thank you guys. I think we can probably like close the channel now. And thanks, Jerome. It's very interesting to see you drawing live. Thank you. I'm still practicing. That was brilliant. I would love to be able to do something like this. And I know that it's mostly practice. And yeah, but... I would like to be able to read the GVM completely and understand all the old parameter and how do you manage your survival garbage collection and then old and stuff like this to optimize responsive and non-responsive applications. And it's still more practice. Yeah, I can connect it to some people who know. It's my past, I leave it behind me. Okay, thank you everyone. So have a good night, have a good day. And yeah, see you next time. See you next time. Cheers. Bye-bye. Bye-bye.