Eclipse OpenJ9 performance; a bake-off on Windows

 

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

Startup performance

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’.

Memory footprint

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:

    1. -Xquickstart is 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.
    2. -Xtune:virtualized is 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 -Xquickstart.

 

The contest: comparing Eclipse OpenJ9 with HotSpot

The two contenders in this bake-off are OpenJDK9 with HotSpot and OpenJDK9 with OpenJ9, which can be obtained as pre-built binaries from the AdoptOpenjdk project.

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.

eclipse_startup

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.

eclipse_footprint

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. 

Further reading

  • 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.

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s