I love talks in which you learn new things in the first 5 minutes. I learned about javap (20 years of Java and I never knew...) and also how bytecode changed between Java 8 and Java 9. https://twitter.com/InfoQ/status/1314315137109684231

It's pretty amazing. Apparently println("string" + int) used to become a stringbuilder, and is now replaced with more efficient concat operation.

Everyone who replaced "string"+int with stringbuilder because conventional wisdom said its faster missed out on Java 9+ optimization. Ouch.

Minute 6 and you learn how classes, methods and variables are represented by the klass object, and a link to "write your own classloader" example: https://github.com/jpgough/watching-classloader/blob/master/src/com/example/classloaders/WatchingClassLoader.java
Must be the most knowledge-dense talk I've watched.

JVM Interpreter starts by *not compiling* anything. It avoids compiling methods you only use once or twice. It monitors the behavior of the application, creates profiles and decides how to compile and how to apply optimizations.

Hotspot JIT uses (used?) C2 compiler, written in C++. But C++ has issues - safety, legacy ways of doing things, limited tooling - all the reasons Java was invented. Also, Java is now fast. Is it fast enough to be a compiler?

JVM now has a compiler interface, so you can replace the compiler. Graal has a JIT compiler written in Java.

You use mx to build the Graal compiler, and then you can use it to run a VM with the graal compiler in it: https://github.com/graalvm/mx  (minute 19ish)

There's an Oracle tool called idealGraph that lets you explore the compilation phases.

Minute 22: James Gough starts debugging the Graal compiler, live (or more likely, pre-recorded, but still!)

The JIT compiler runs in a separate thread than your application, so while it is compiling your application is running via the interpreter. It makes sense, but I never thought of this.

When you run an application that is running on a JVM with Graal compiler, it starts by compiling itself. So there is this initial slowdown. Was cool to see this via println inserted into the compiler :)

Remember that the compiler is on another thread - if your program is very short, it will complete its execution before Graal is done compiling.

JIT compilation allows you to use the runtime profiling data to eliminate code that is never used in that particular execution.

It can also decide to allocate small objects that are limited in scope on the stack. This reduces GC pressure.

"The more you use the latest version of Java, the more performance benefits you get for free" <- Also true for @apachekafka. I think this is the hallmark of any live critical infrastructure.

Hotspot also optimizes away the method lookup - replacing the vtable lookup with direct reference. And if class-loader shenanigans happen, it de-optimizes that back to lookups.

AOT - ahead of time compilation. Replacing the "code cache" that JIT creates (at cost of slow startup time). Slow startup time and a memory spike is not what you want if you are running in the cloud.

Sorry, AOT is an extension of the code cache. So you can use this together with JIT.

jaotc tool - takes a classfile and gives you a shared object. Then you can pass these to the JVM as the AOT Library. Unfortunately, there are currently no build tools around that. But no worries - James is on it! Maven plugin on the way!

If you have a performance problem - don't start with the compiler! It is more likely to be - network, IO, databases, maybe GC. Take a profile of the app and proceed from there.

James didn't do a direct compare of AOT and JIT - but clearly, there are optimizations that are only possible in runtime and you lose those, but you get faster startup.

He also didn't exactly talk about how JIT and AOT interact and that's a bit interesting - can the profile built by the interpreter cause the JVM to replace AOT code with better JIT code? maybe we can have the best of both worlds?

Ah, GraalVM lets you supply a profile to the AOT compiler, so you can use "hints" to the compiler from actual execution.

"We are out of time, which means its beer o'clock". Welp, I'll go and grab one. You go watch the talk. I didn't capture even 10% of its awesomeness in this thread.