To date, all of the experiments we’ve used to showcase the performance of the OpenJ9 JVM were carried out on Linux. So in this article we will look at how OpenJ9 fairs on Windows. Because Windows is often used as a development platform and Eclipse is the most popular integrated development environment written in Java, we chose to evaluate the performance of OpenJ9 when launching an instance of the Eclipse IDE.
The bake-off score sheet: performance metrics
Software developers want their graphical tools to start-up quickly and smoothly without any lag or stutter. For ease of measurement, we’ll focus on start-up time and ignore ‘smoothness’.
We’ll also look at memory footprint. Developers often have many applications and tools open at the same time, tools that might consume most of the RAM available on their desktop or laptop. Therefore, using less memory in Eclipse can sometimes be important.
Ingredients: OpenJ9 configuration
Two features that were designed to help with start-up performance in the OpenJ9 JVM are the shared class cache (SCC) and dynamic Ahead-Of-Time (AOT) compilation. You can enable both of these features with the
-Xshareclasses option, which is described in the OpenJ9 documentation.
Because the default size of the SCC is relatively small and Eclipse IDE is a rather large application, we configured a 100MB cache by specifying
-Xscmx100m. We also used a Class Data Sharing (CDS) adaptor that allows many of the Java classes loaded by the OSGi framework to be stored in the SCC.
OpenJ9 has internal heuristics that decide when to generate AOT code. In order to minimize start-up time, we want the JVM to bypass those heuristics and generate AOT code as much as possible. There are two supported ways of achieving this goal:
-Xquickstartis recommended for short running applications where (a) there isn’t enough time to get a return on the cost of JIT compilations, (b) applications may feel jerky due to JIT compiler interference (e.g. graphical applications), or (c) simply for cases where start-up time is the most important performance criterion. This option is not a good fit for long running, transaction-oriented applications because it can degrade throughput significantly.
-Xtune:virtualizedis a good option for resource constrained environments that are typically found in the cloud. When enabled, the JVM uses cheaper JIT compilations and it is more conservative with JIT re-compilations and memory consumption without unduly sacrificing throughput.
In these experiments we will use
-Xtune:virtualized since it gives a small advantage over
The contest: comparing Eclipse OpenJ9 with HotSpot
As shown in the following graph, without any tuning, OpenJ9 takes more time than HotSpot to start-up the Eclipse IDE. However, using SCC and AOT code has a big effect, cutting start-up time in half. Adding
-Xtune:virtualized into the equation improves start-up time by another 11%, making OpenJ9 43% faster than HotSpot.
If we take a look at footprint, the results are equally outstanding. As shown in the next chart, regardless of the configuration, OpenJ9 uses about 42% less memory than Hotspot.
So the next time you need to spin up your Eclipse IDE to tackle some coding, remember this bake-off contest and pop over to AdoptOpenJDK.net to grab a pre-built binary of OpenJDK with Eclipse OpenJ9 for Windows.
Breaking news: We’re pleased to report that the Eclipse Foundation Board have approved the distribution of OpenJ9 as part of the Eclipse IDE in a future release.
- Find out more about class data sharing in this article.
- If you want to see the full recipe behind the performance testing in this experiment, we’ll be publishing the results on our website in the near future.
- For other performance comparisons with OpenJDK 8 and OpenJDK 9 on Linux, visit our website.