CRaC is an OpenJDK project developed by Azul to solve the problem of “slow” startup times of the JVM in a microservice environment.
-
What Does a Modern JVM Look Like, And How Does It Work?
In this article, the internal workings of the JVM are discussed, e.g., interpreter, JIT compiler, and how it optimizes code.
-
Quest to the OS: Java Native Memory
Let’s embark on an epic journey to the wonderland of java native memory to the level of OS while investing in a non-trivial memory issue.
-
Kover : Code Coverage plugin for Kotlin
TL;DR : Kover is a code coverage tool for Kotlin. It’s still in incubator phase but I took it for a spin and it is already very useful as part of local or CI workflows! In this article I go …
-
Measuring Time and Duration in Kotlin
The DurationAPI is coming out of its experimental stage and offers a nice DSL to easily work with time durations.
-
No-Cost IBM Semeru Runtimes for Java
With the launch of IBM Semeru Runtimes, IBM makes it easier than ever to develop and run Java applications more cost-effectively in hybrid cloud environments, from public cloud to data centers.
IBM Semeru Runtimes use the class libraries from OpenJDK, along with the Eclipse OpenJ9 Java Virtual Machine to enable developers to build and deploy Java applications that will start quickly, deliver great performance, all while using less memory.
-
Concurrency in Java (and How it Compares with Other Modern Programming Languages)
This is a multi-part series where I talk about concurrency in modern programming languages and build and benchmark a concurrent web server, inspired by the example from the Rust book, in popular languages like Java, Rust, Go, JavaScript (NodeJS), TypeScript (Deno) and Kotlin to compare concurrency and its performance between these languages/platforms.
Part 6 is here on Foojay.io, the place for friends of OpenJDK.
-
🚀 Demystifying JVM Memory Management
In this multi-part series, I aim to demystify the concepts behind memory management and take a deeper look at memory management in some of the modern programming languages, in particular Java, Kotlin, Scala, Groovy, and Clojure.
I hope the series would give you some insights into what is happening under the hood of these languages in terms of memory management.
In this chapter, we will look at the memory management of the Java Virtual Machine (JVM) used by languages like Java, Kotlin, Scala, Clojure, Groovy, and so on.
-
Embracing JVM unified logging (JEP-158 / JEP-271)
In the previous blog post, I briefly introduced unified logging and a simple GC configuration. However for the savvy GC tuners, there are many more options. And there are other logging options that transitionned to unified logging infrastructure as well.
I wasn’t satisfied with the official documentation and other blog posts as they usually present only a fragmented picture of the previous options. This led me to dig in.
-
Introduction to JVM Unified Logging (JEP-158 / JEP-271)
Unified logging was introduced in JDK 9, and is available for us all, in the JDK 11 LTS. Like other great serviceability feature (jcmd or JFR) this was inspired by JRockit.
In my opinion the flexibility of this logging system brought a major downside from a user’s perspective in its configuration correctness, and I think in some ways it’s more obscure compared to the previous explicit logging flags.
-
What is JVM Bytecode?
Everyone who programs in Java, or any of the other languages built on top of the Java Virtual Machine (Scala, Closure, Kotlin, Groovy, Nashorn, Jython, JRuby, et al.) is familiar with the term “bytecode.”
But how many of us understand what JDK bytecode actually is?