2 December 2021

Java Flight Recorder: Knocking on the Java & Kotlin apps profiling doors

The goal of this article is to examine the possibilities of profiling a Kotlin and a similar Java application with JMC/Java Flight Recorder[1] to get a better understanding of their behavior compared to each other. Nowadays the IT world often spells terms like SRE[5] or latencies, but how to measure this in an accurate way without relying on “random” samples. The exact answer to this question is out of the scope, but we can show what possibilities there are for understanding and measuring the behavior of an application in regard to these aspects based on simple examples using the JFR.

Starting slowly: what is the JVM? The JVM stands for Java Virtual Machine. The JVM enables a computer to run Java programs, but not just that. JVM supports all languages that are able to be compiled into the Java byte-code. All good so far, but what is the JMC/JFR[1] ?

The letters JFR stand for the Java Flight Recorder, which is an event-based tool build directly into the JVM. Exciting, isn’t it ? The JFR can provide a view to the JVM internals through emitted events and more…

The purpose of this article is to compare a Kotlin and a Java app and touch “hidden” compiled code compositions. Let’s briefly introduce Kotlin first as Java has been around for quite a while. I would even bet a couple of million articles have already been written about Java, so it’s fair to have just a short Kotlin introduction.

Kotlin belongs to the JVM language family. It was introduced in 2011 as a new language for JVM and has been developed by JetBrains. The communicated goal was to become a “better language” for the JVM. Kotlin has since been successfully adopted by the Android community and is gaining ground on the backend as well. In short, Kotlin is an object-oriented statistically typed language. It offers a set of quite handy features and traits such as: data classes, concise, safety, smart casting, functional capabilities etc.

Perhaps because of these often spelled Kotlin “benefits”, nowadays more companies are thinking about or are already using a Kotlin stack for backend development. The reason for this may seem obvious,but there are different perspectives for this choice and a discussion about it may turn into chicken-egg arguments. This is also out of the scope of this article.

I have put the word “benefits” in the previous paragraphs between apostrophes intentionally as some nice concepts may look very neat in Kotlin, but they may not be as optimized as Java’s counterpart (considering latest Java builds)! The Java Ecosystem evolves pretty fast and Java stays the 1st JVM language and also the most optimized one. But nonetheless Kotlin has many nice constructs ( an usage of when-smart-casting or type references). Such constructs can help teams move faster without causing unwanted issues. An example of such an issue is the well known NPE (Null Pointer Exception) .

Let’s profile

The introduction is done. Let’s now compare the characteristics of a comparable Java & Kotlin app using the JMC/JFR! First we share the setup. For each measurement we use the current development state of the JMC/Java Flight Recorder - Early Access[1]. Each measurement is done in a 45 seconds time window. All examples use OpenJDK 17[4].

We used the following 2 examples [2] to get some measurable data:

1. Hot-Methods
2. Latencies

Each example uses similar JMC/JFR Events. Such events wrap equivalent sections of the application (Java/Kotlin) to obtain comparable results. The application Threads are reduced in both cases in order to -again - obtain comparable results. This means any detailed platform configuration is avoided as the goal is to compare basic platform configuration.

Hot-Methods Example

The idea of this simple app is to have two “containers” held by the individual “worker”. Those two containers each hold their own collection of numbers. The worker tries to find an intersection of those paired containers (see Img.1. in Kotlin, similar in Java)

Img.1.: Example worker code - Kotlin

After running the 1st not fixed code for 45 seconds we obtain the Java app following result:

Img.2.: Hot-Methods example: Java app - 431 400 events emitted

We now repeat this process for the Kotlin version of the similar application for 45 seconds and obtain the following results:

Img.3.: Hot-Methods example: Kotlin app - 408 403 events emitted

Let’s fix the code for both apps and observe the improvements in throughput on both sides. We publish only the amount of JFR events that have been emitted (Img.4.) as this is the identifier of the improvement that have been achieved:

Img.4.: Hot-Methods example Java, Kotlin comparison results

Well, pretty interesting, don’t you think. Before making conclusions, let’s go to the next example.

Latency Example

The second example is based on getting insights into latency that can be caused by many factors. It could be unnecessary garbage collection, network issues, or improper synchronization inside the application. In our current example we consider a problematic logger (Img.5.) that has a corrupted method “log” that is synchronized. It means it forces each thread to wait for it.

Img.5.: Problematic Logger method

The Kotlin application uses the concept of Mutex (Kotlin Interface, coroutines library)[6] to enforce synchronization. Let’s take a look at the measurements. We try to answer the question of how many events can be emitted from the corrupted code in a 45 seconds time window (Img.6.: Java, Img.7.: Kotlin)

Img.6.: Java Problematic logger results, 222 JFR events

When we run the Kotlin application we receive almost identical results:

Img.7.: Kotlin Problematic logger result, 222 JFR events

After fixing the problematic logger we obtain the following results (Img.8.: Java, Img.9.: Kotlin). The results show that the blocking issue has been removed:

Img.8.: Java fixed logger, 957 JFR events

How is the Kotlin app doing?

Img.9.: Kotlin fixed logger, 808 JFR events

Conclusion

Watching the results we can observe that the results in both applications are very comparable!

Important to note: the time window for the examples was just 45 seconds and the examples were more set up from a research perspective to highlight a specific issue.

We have seen the possibilities that are provided to us by the Java Platform in order to create our application better and understand the behavior in more detail. Mainly, by demonstrating the possibilities the Java Flight Recorder[1] brought to us.

We have also discovered, in a bit more detail, a composition of the Kotlin coroutines framework[7] (asynchronous and non-blocking library)

Hope that the article helped to increase an awareness about JMC/JFR[1] possibilities, how it can be utilized in app development and you had fun comparing Java and Kotlin along the way.

Stay Tuned and Happy Profiling!

References

1. Java Mission Control Project
2. JMC-JVM-Lang tutorial: profiling examples for different languages
3. JMC-tutorial examples by Markus Hirt
4. OpenJDK 17
5. Site Reliability Engineering - SRE
6. Kotlin, Mutex
7. Kotlin, Coroutines Framework

---