I have to do some performance tuning in our application API and I've been researching the JVM flags regarding Heap Size and Gargabe collection. However, I often find myself in many different documentations, sometimes I end up in WebLogic Servers docs or some other enterprise version of the java ecossystem.
I've considered testing flags that are common to all JVM's, I've read some of them are more common and are present in almost all JVM's, whereas some are more specific, like the -XX ones, are more JVM specific.
My guess is that this https://openjdk.java.net/groups/hotspot/ is the answer, but I was wondering if anyone had any more concrete info. I've run a command at home (not the application at my job, but the result seems to be the same, except for the java version) to get some info at home in a process, just to compare:
root@xxxx:/home/xxxx# jcmd 6134 VM.system_properties > log.out
root@xxxx:/home/xxxx# cat log.out | grep vm
java.vm.vendor=Ubuntu
java.vm.specification.version=11
sun.boot.library.path=/usr/lib/jvm/java-11-openjdk-amd64/lib
java.home=/usr/lib/jvm/java-11-openjdk-amd64
java.vm.compressedOopsMode=Zero based
java.vm.specification.vendor=Oracle Corporation
java.vm.name=OpenJDK 64-Bit Server VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.info=mixed mode, sharing
java.vm.version=11.0.11+9-Ubuntu-0ubuntu2.18.04
root@xxxx:/home/xxx#
As you can see it just states OpenJDK 64-Bit Server VM, as the jvm name. If I try to search on google for the flags, it falls back to HotSpot, hence my doubt.
I've already used the command that lists all JVM flags to see the options, so that's already a good thing. However the official documentation would also be nice, I've been going on different JVM specifications hoping that the meaning of the flag would be the same, but it does cause me the feeling I don't know what I'm doing.
So, maybe a TL:DR: can OpenJDK 64-Bit Server VM be interpreted as the HotSpot JVM, or should I look for its docs somewhere else?
JDKs come with different JVM implementations (HotSpot, OpenJ9, GraalVM), and varied garbage collector implementations with different tuning options (Z Garbage Collector (ZGC), Garbage-First (G1), Shenandoah, Concurrent Mark Sweep (CMS), Serial Collector, Parallel Collector, etc.)
There are two JVM implementations for general-purpose Java work:
Both JVMs are excellent and well proven. As for comparing, commentators frequently refer to OpenJ9 being faster to start with less initial memory demanded, while HotSpot may be more optimal for execution over time. But do your own research to choose. Remember you are comparing apples and apples here, not apples and oranges.
Many JDK distributions are available from several vendors, including Azul Systems, Red Hat/IBM, SAP, Microsoft, Oracle, Pivotal, BellSoft, Amazon, and others. Some vendors use HotSpot, and some use OpenJ9. Some offer both, allowing you a choice. For example, here is a screenshot from AdoptOpenJDK a.k.a. Adoptium, offering the choice of HotSpot or OpenJ9.
As for how to identify which is in use at runtime, I cannot help there.
By the way, understand that the OpenJDK project covers many subprojects. HotSpot is only one of several subproject. An implementation of the core libraries we’ve come to know as the Java API is another subproject. Others subprojects are preparing technologies, such as Project Panama and Project Loom.
Vendors providing a JDK build/installer are free to pick-and-choose these parts. A vendor may choose to use the core libraries from the subproject of OpenJDK combined with the OpenJ9 JVM from the Eclipse Foundation.
Also understand that the OpenJDK project provides only the raw source code for these parts of a JDK. The OpenJDK project does not provide builds/installers. Look to the other vendors mentioned above for builds/installers.
Oracle restricts access to their trademark for the name and logo of “Java”. In contrast, Oracle provides easy access to the term “OpenJDK” for use in naming the builds and installers that are based on the OpenJDK codebase. So many of the JDK products released by various vendors have "OpenJDK" in their name, but that means they are based on the OpenJDK codebase, not that the build/installer was provided by the OpenJDK project — a subtle but important distinction.
Another JVM coming into its own nowadays is GraalVM. This JVM is special. Features include: