How and Why GraalVM is quickly becoming relevant for developers (ACEs@home - June 2020)

Editor's Notes

• #3: Run PrimeNumbers – what happens? JRE startup Interpreted mode After some time: JIT compilation of Java byte code to machine code; After more time: runtime optimization; runs on GraalVM What is size of runtime environment: Class file + JRE; memory footprint: 10 – 150 MB Run native primes – what happens: instant start/execution of already natively compiled machined code Runtime: just the executable (size 10MB) Performance and [low] Resource Usage of Ahead of Time Compiled Java application
• #4: Run HelloWorld – what happens? JRE startup JIT compilation of Java byte code to machine code; runtime optimization; runs on GraalVM What is size of runtime environment: Class file + JRE; memory footprint: 10 – 150 MB Run native helloworld – what happens: instant start/execution of already natively compiled machined code Runtime: just the executable (size 10MB) Performance and [low] Resource Usage of Ahead of Time Compiled Java application
• #5: Overview of main themes and topics (instead of boring list of all topics in the agenda) We can make this slide build – to indicate the order of the topics High-performance modern Java Low-footprint, fast-startup Java Combine JavaScript, Java, Ruby, and R
• #6: Spaghetti… Hotspot C2 compiler for runtime optimizations had gotten very complicated and very hard to maintain. It does not support optimization for modern code patterns. The C++ code had gotten out of hand
• #10: https://en.wikipedia.org/wiki/GraalVM
• #11: https://openjdk.java.net/projects/graal/
• #12: Spaghetti… Hotspot C2 compiler for runtime optimizations had gotten very complicated and very hard to maintain. It does not support optimization for modern code patterns. The C++ code had gotten out of hand
• #13: https://blogs.oracle.com/graalvm/accelerating-oci-applications-with-graalvm-enterprise  For OCI user workloads, GraalVM Enterprise can be used in the following deployment scenarios: Bare Metal and Virtual Machines (OCI Compute) Containers (Oracle Container Engine for Kubernetes) Functions (Oracle Functions)
• #17: Human Languages Computer Programming Languages (personal taste, libraries, suitability for certain tasks, legacy) Office politics, commercial
• #18: Human Languages Computer Programming Languages (personal taste, libraries, suitability for certain tasks, legacy) Office politics, commercial
• #21: At this part of our presentation, we will focus on JVM-based languages and try to explain the difference between 2 compilation modes provided by GraalVM.
• #22: Let's start with (JIT) Just in Time compiler. This is the default way of compiling JVM based applications.JVM is a run-time environment that interprets Java application into Java bytecode and then uses something called a (JIT) just-in-time compiler which compiles the Java bytecode into native machine code while you are running your application.This means that a Java application gets more optimized and faster while running and this is also the reason why Java gets as fast as it is and how it can run some code faster than C++ Java HotSpot VM has two JIT compilers.C1 also called the client compiler. C1 create your first machine code. You do that because there's such a big difference between the interpreter speed and the final machine code speed. So, you need an intermediate solution. This intermediate solution is provided by the C1 client compiler, and this intermediate solution has something in there that gathers profiling feedback, information about how the application is running the code. Then, when a method gets really hot, meaning method is executed around 10.000 times, then the method is scheduled for the second compiler, and this is when the heavyweight compiler, C2 compiler, comes in and uses all the information gathered during the startup sequence of the application to create the final, very optimized machine code and then you execute faster. These HotSpot compilers exist for a while and optimized for certain workloads but the way how we program has changed over time. How we use today JVM is very different from what we did 20 years ago. Today we run on JVM other languages like Groovy and Scala. So there are different constructs that are reaching JIT compiler and some of the optimization phases that have been originally placed in compilers are not taking into account the complexity of those new constructs.So, when focusing on modern programs running on top of JVM we could do a better job by writing a new optimization phase for this new type of program. In this context, GraalVM replaces HotSpot's C2 compiler.GraalVM is designed for optimization of modern code shapes, such as Scala or Kotlin but also for modern types of Java code, for example, if you use latest stream API expressions or even lambdas.Only production implementation of GraalVM is in this domain, by Twitter. Where Twitter is using GraalVM to compile Scala code.Enabling their microservices to use less memory with improvements in garbage collection. Less CPU spent on GC.
• #23: But let's look at a different compilation mode, which is unique to GraalVM and that is (AOT) Ahead of Time compilation. GraalVM has a way that takes a JVM based application and then does so-called Closed World Analysis, where it figures out all the code that is reachable from the application entry point and triggers Ahead of Time compiler which creates machine code, a binary that can run by its own with no need for JVM to be present! Also known as Java native image. You can also statically link system library, with --static flag when you are creating native binary and in that case, you can run that native binary on bear metal docker image. So, you don't even need a Linux distribution or anything like that when you run on Docker.
• #24: So let's see what is all happening in this Ahead of Time compiler in order to produce a native image. At first step as input, GraalVM is taking everything that is consumed by the Java application, meaning the libraries, the JDK libraries, also resource like SubstrateVM, and what it does is a Closed World Analysis. Closed World Analysis is an analysis of all reachable methods, fields and classes from the main class of the application. Because when you create this package binary, you don't want to include every JDK class there is, you don't want to include every library class there is. You want to package only what is used by your application, so Graal does a point-to analysis of what is reachable from the entry point of the application. Graal runs some of the static initializers and creates heap snapshots. Then, we put everything together in a single binary. We put all the code AOT compiled code into the machine code section, and we write down a snapshot of the Java application as it was when initialized into the image heap section. This allows us to pre-initialize certain values or configuration parameters of the application, and we don't need to load them again when we start this binary. This binary has a GC inside, so it still has some run-time system but it does no longer contain interpreter nor JIT compiler.AOT has a less advanced GC comparing it with JIT GC and no profiling data is collected for further improvement like in JIT Startup time is probably the area where the Ahead of Time compilation is beating the JIT compilation by the largest margin
• #25: Native Image does not support all features of JIT.Dynamic class loading is not supported, and cannot be supported by Graal AOT execution model. During native image generation, Graal runs an aggressive static analysis that requires a closed-world assumption. For that, Graal needs to know all classes and all bytecodes that are ever reachable. Reflection. Some types of Reflection are automatically detected by Graal and some more complex cases need an additional configuration. Reflection needs to be known, flagged ahead-of-time. Native Image tries to resolve these elements through a static analysis that detects calls to the reflection API. Security Manager. Since there is no dynamic class loading, there is also no need for this feature. JMX. These interfaces require access to Java bytecodes, which are no longer available at run time. If your code is not using Dynamic class loading and you handle reflection cases carefully you should be good to go.
• #26: First of all you load the classes, the Java byte codes from your disk, then you have to verify the byte codes, then you start interpreting your byte codes. And then what you do on the Java HotSpot virtual machine is that you create a first-tier compilation. You use a fast compiler, which is C1, the client compiler of HotSpot to create your first machine code. You do that because you want to speed up your application as fast as possible. Then, when a method gets really hot, meaning you've had to first compile, you've got some profile, then the method is scheduled for the second compiler, and this is when the heavyweight compiler, either the C2 compiler or the GraalVM compiler comes in and uses all the information gathered during the startup sequence of the application to create the final, hopefully, very good machine code, and then you execute faster.  As you can see there's a long sequence here, and this is the main reason why an application that is running on the Java Virtual Machine is starting up slowly.
• #27: First of all you load the classes, the Java byte codes from your disk, then you have to verify the byte codes, then you start interpreting your byte codes. And then what you do on the Java HotSpot virtual machine is that you create a first-tier compilation. You use a fast compiler, which is C1, the client compiler of HotSpot to create your first machine code. You do that because you want to speed up your application as fast as possible. Then, when a method gets really hot, meaning you've had to first compile, you've got some profile, then the method is scheduled for the second compiler, and this is when the heavyweight compiler, either the C2 compiler or the GraalVM compiler comes in and uses all the information gathered during the startup sequence of the application to create the final, hopefully, very good machine code, and then you execute faster.  As you can see there's a long sequence here, and this is the main reason why an application that is running on the Java Virtual Machine is starting up slowly.
• #29: When we are comparing AOT vs JIT compiler we can notice that AOT mode focusses on maximized startup time, memory footprint and packaging size.And we should still use JIT when Peak Throughput and Max Latency are important.Also, the nature of how you run your application is important. For example, if the run time of your application is measured in weeks or months and the size of your heap is huge, then JIT compiler will provide you most benefits. But if you are running a small service (microservice) or even a (serverless) function, where the runtime is measured in hours, minutes, seconds then you should try AOT. can we get AOT better? There are a couple things we're currently exploring to get AOT better on the areas where the JIT compiler currently is better. One is the profile guided optimizations where we collect the profiles up-front. Another one is we're working on a low-latency GC option also for the native images. This puts at least some max latency, the two versions at the same level. Then, we are continuously working to improve the way you can create native images by having, for example, a tracing agent that will automatically create your configuration. Currently, if you want to use native images, the best bet is to use one of the frameworks that has support for it, meaning, Helidon, Micronaut, or Quarkus, because those frameworks help you with some of the configurations you need to create that small thing.
• #30: Saying this all, there are already few frameworks that have adopted GraalVM and the concept of native Java images and they all are targeting cloud-native microservices: Containers (cost of cloud resources, memory) Serverless (startup time of functions)Polyglot development  In a later demo, we will dive deeper into the world of Quarkus. A supersonic, subatomic, cloud-native Java framework.
• #42: https://www.npmjs.com/package/validator
• #43: https://www.npmjs.com/package/validator
• #44: https://www.npmjs.com/package/validator
• #45: https://www.npmjs.com/package/validator
• #49: https://www.npmjs.com/package/validator
• #50: https://www.npmjs.com/package/validator
• #51: https://www.npmjs.com/package/validator https://www.graalvm.org/docs/reference-manual/compatibility/#validator
• #52: https://www.npmjs.com/package/validator https://www.graalvm.org/docs/reference-manual/compatibility/#validator
• #53: https://www.npmjs.com/package/validator https://www.graalvm.org/docs/reference-manual/compatibility/#validator
• #54: https://www.npmjs.com/package/validator
• #61: var FileClass = Java.type('java.io.File'); var file = new FileClass("myFile.md"); https://www.graalvm.org/docs/reference-manual/languages/js/ https://github.com/graalvm/graaljs/blob/master/docs/user/JavaInterop.md Node.js applications running on GraalVM's JavaScript engine have access to all of Node.js' APIs, including built-in Node.js' modules such as 'fs', 'http', etc. Conversely, JavaScript code embedded in a Java application has access to limited capabilities, as specified through the Context API, and do not have access to Node.js' built-in modules.
• #62: var FileClass = Java.type('java.io.File'); var file = new FileClass("myFile.md"); https://www.graalvm.org/docs/reference-manual/languages/js/ https://github.com/graalvm/graaljs/blob/master/docs/user/JavaInterop.md Node.js applications running on GraalVM's JavaScript engine have access to all of Node.js' APIs, including built-in Node.js' modules such as 'fs', 'http', etc. Conversely, JavaScript code embedded in a Java application has access to limited capabilities, as specified through the Context API, and do not have access to Node.js' built-in modules.
• #63: https://www.graalvm.org/docs/reference-manual/languages/js/ https://github.com/graalvm/graaljs/blob/master/docs/user/JavaInterop.md Node.js applications running on GraalVM's JavaScript engine have access to all of Node.js' APIs, including built-in Node.js' modules such as 'fs', 'http', etc. Conversely, JavaScript code embedded in a Java application has access to limited capabilities, as specified through the Context API, and do not have access to Node.js' built-in modules.
• #65: https://www.graalvm.org/docs/reference-manual/tools
• #66: https://visualvm.github.io/graal.html https://github.com/oracle/graal/tree/master/vscode/graalvm https://www.graalvm.org/docs/reference-manual/tools/#visual-studio-code-extensions-for-graalvm https://www.graalvm.org/docs/reference-manual/tools/