Eclipse OpenJ9
Eclipse Incubation

What's new?

Covering project news, events, milestones, and of course... new and cool stuff!

Eclipse OpenJ9 version 0.17.0 released

18th October 2019

OpenJ9 version 0.17.0 supports OpenJDK 8, 11, and 13. OpenJDK builds that contain Eclipse OpenJ9 version 0.17.0 are now available from the AdoptOpenJDK community project:

OpenJDK version 8
OpenJDK version 11
OpenJDK version 13

Note: The last release of OpenJDK 8 and 11 from AdoptOpenJDK is Eclipse OpenJ9 0.15.1. To read about other features and changes in the VM since 0.15.1, check the Version 0.16.0 release notes too.

Here are some of the new features that we've introduced in version 0.17.0 of OpenJ9. You can control the behavior of all the default settings mentioned with appropriate command-line options.

Do let us know how well these enhancements work for you by posting in our slack channel.

  • z15 processor support. This release adds JIT compiler support for exploiting z15 processor instructions.
  • New shared classes cache suboption to skip disk space check. When creating a persistent shared classes cache, the OpenJ9 VM checks that there is sufficient disk space available on the file system. For file systems that do not support the checking of free space, you can set the -Xshareclasses:noPersistentDiskSpaceCheck option, which causes the VM to skip the space checking operation. If there isn't enough disk space available when the cache is written, a SIGBUS or SIGSEGV signal occurs and the VM ends.
  • "Unsafe" classes are stored in the shared classes cache. By default, classes created through Unsafe.defineClass are now stored in the shared classes cache. You can use the -XX:-ShareUnsafeClasses option to change this behavior.
  • There is now an option to record class relationships in the verifier. A new command line option -XX:+ClassRelationshipVerifier allows you to record class relationships in the verifier, which avoids unnecessary class loading and reduces VM startup time. This is a new approach to bytecode verification that delays validating the relationships between classes until the classes are required to be loaded for a program's execution thus loading only those classes that are needed.
  • You can now create layered caches (64-bit only). Where a cache builds on another cache with the same name, you can use suboptions for -Xshareclasses to create layered caches and save space: good for building a Docker container, for example. The suboptions are: createLayer, layer=<number>, printTopLayerStats, and destroyAllLayers. Note: These suboptions are experimental, so do not use them in a production environment.
  • The restriction on Direct Dump Reader (DDR) has been removed. Prior to this version, you had to use a 32-bit VM to look at a 32-bit core, and a 64-bit VM to look at a 64-bit core when using DDR. This restriction has now been removed.
  • The format of the HOOKS section of a Java dump has changed to show recorded times in microseconds to provide increased precision. There is also a new field, 3HKTOTALTIME, which gives the total duration of previous events. For more information and an example of the new format, see documentation for Java dump.
  • LUDCL caching disabled by default. By caching the Latest User Defined Class Loader (LUDCL), Java applications that use deserialization extensively can see a performance improvement. This capability is controlled by the system property and is now disabled by default. (Note that previous versions of the documentation incorrectly identified this property as disabled by default when it was actually enabled by default in the VM.)
  • Support for the Digest algorithm is re-enabled. For more information about this support, see Cryptographic operations in the documentation.
To read more about the changes in version 0.17.0, read the Release notes in the OpenJ9 user documentation, which will also give you detailed information about the options mentioned here.

Eclipse OpenJ9 version 0.16.0 released

17th September 2019

OpenJDK builds that contain Eclipse OpenJ9 version 0.16.0 are now available from the AdoptOpenJDK community project

OpenJ9 version 0.16.0 supports only OpenJDK version 13, the latest release of the Java SE Platform.

Here are some of the new features that we've introduced in version 0.16.0 of OpenJ9. You can control the behavior of all the default settings mentioned with appropriate command-line options.

As indicated, many of these enhancements will typically improve the performance of your applications. As always, you can let us know how well these performance enhancements work for you by posting in our slack channel.

  • Class data sharing is enabled by default for bootstrap classes, unless your application is running in a container. We've seen an improved Tomcat startup time of almost 30% with an out-of-the-box configuration.
  • When you use the madvise setting on Linux on x86 systems, Transparent Huge Pages (THP) is now enabled by default. The THP setting on other systems remains disabled by default when you use madvise.
  • For compatibility with the reference implementation, OpenJ9 now includes an independent implementation of the jcmd tool for running diagnostic commands on a VM.
  • Shared classes:
    • Anonymous classes, those created by Unsafe.defineAnonymousClass, are now stored in the shared classes cache by default, which means they are available for ahead-of-time (AOT) compilation, potentially improving startup performance.
    • The use at startup of GC hints in the shared classes cache to guide the expansion and sizing of the Java heap is now enabled by default as it speeds up startup time by taking advantage of the information stored from a prior run in the shared classes cache. It typically provides 3-4% improvement in Open Liberty startup time.
  • Compilation counts for AOT compilations are lowered, which improves startup time for methods that do not get invoked many times. This also improves the startup time of lighter weight frameworks. There is typically a 3-4% improvement in startup time in Open Liberty and with lighter weight frameworks such as Quarkus.
  • Improvements in escape analysis allow optimizations to function better, in particular to cope with hot code replacement (HCR).
  • Version 0.16.0 also sees JSR-292 (method handle) related performance improvements to method inlining and type propagation.
To read more about the changes in version 0.16.0, read the Release notes in the OpenJ9 user documentation.

Eclipse OpenJ9 version 0.15.1 released

17th July 2019

OpenJDK builds that contain Eclipse OpenJ9 version 0.15.1 with the latest Critical Patch Update (CPU) are now available from the AdoptOpenJDK community project

We've introduced some cognitive behavior in this release to improve startup performance. OpenJ9 can now learn and set an appropriate initial heap size for an application as an alternative to a user manually sizing and setting an -Xms value. The VM records the size of the heap when startup processing ends, writing this data to the shared classes cache. An average value is set over a few restarts, helping to ensure that the value used for the initial heap size is as accurate as possible. This feature is expected to become the default in a future release. To enable it now, ensure that shared classes are turned on (-Xshareclasses) and set the -XX:+UseGCStartupHints option on the command line when you start your application. Our testing demonstrates ~5% startup improvement for Open Liberty, so give it a go and post in our slack channel to let us know how well it works for you.

In this release, we are also introducing more compatibility changes to help users adopt OpenJ9:

  • We now have an independent implementation of the popular HotSpot jmap tool for obtaining information about classes and objects in memory for a specified process.
  • You can now use the -XX:OnOutofMemoryError command line option to run a specific command when an out of memory error is thrown (a shorter equivalent to our -Xdump:tool:events=systhrow,filter=java/lang/OutOfMemoryError,exec= option)

The following performance features, available in earlier releases for a limited set of platforms, are now extended to Linux on IBM Z® systems:

  • Reduced garbage collection pause times with our Pause-less garbage collection mode (-Xgc:concurrentScavenge)
  • Improved performance for JVMTI watched fields (now enabled by default in this release for x86 as well as Linux on Z)

To read more about the changes in v0.15.1, including low-overhead heap profiling (JEP 331) and ChaCha20 algorithm support in OpenSSL, read the Release notes in the OpenJ9 user documentation.

Eclipse OpenJ9 version 0.14.0 released

18th April 2019

Our latest release is now available, supporting OpenJDK versions 8, 11, and 12. Release builds of OpenJDK with OpenJ9 can be obtained from the AdoptOpenJDK community project , which contain the latest quarterly Critical Patch Update (CPU).

Note: On OpenJDK 8 and 11, OpenSSL pre-requisites have changed. For more information, see AdoptOpenJDK builds.

We've recently been working on improving the performance of JVMTI watched fields. So far, the work is complete only on x86 platforms (Windows®, macOS®, and Linux®), but the results are impressive. A customer who tested adding and removing field watches with the new code reported a ~40X improvement for adding field watches and a ~15X improvement for removing field watches. The function is not currently enabled by default, but if you are interested in giving it a try, you can enable it with the -XX:[+|-]JITInlineWatches option.

To help users adopt OpenJ9, we have continued to work on compatibility with the reference implementation by introducing the following new options and tools:

  • By default, the OpenJ9 VM ignores any -XX: options that it does not recognize, which prevents an application from failing to start. However, if you are switching to OpenJ9 from HotSpot and you set a lot of -XX: options on the command line, you will want to identify which options are ignored and determine whether an equivalent OpenJ9 option is required. Use the -XX:-IgnoreUnrecognizedXXColonOptions option to prevent options being ignored and read Switching to OpenJ9 for a list of compatible options.
  • OpenJ9 now includes a Java stack tool (jstack) that you can use to obtain Java stack traces and thread information for processes. The tool is similar to the HotSpot tool of the same name, but is an independent implementation.
  • The Java process status tool (jps) introduced in OpenJ9 0.13.0 for OpenJDK 12 is now available for OpenJDK 8 and 11 users. Although similar in function to the HotSpot jps tool, it is implemented differently by using the Attach API.

Other changes in this release include support for OpenSSL v1.0.2 (OpenJDK 8 & 11) and improved platform support for our pause-less garbage collection mode of the gencon policy.

To find out more about the changes in v0.14.0, read the Release notes in the OpenJ9 user documentation.

Eclipse OpenJ9 version 0.13.0 released

20th March 2019

OpenJ9 version 0.13.0 adds support for OpenJDK version 12, the latest release of the Java SE Platform. Builds of OpenJDK with OpenJ9 are now available at the AdoptOpenJDK community project .

Note: OpenSSL pre-requisites have changed. For more information, see AdoptOpenJDK builds.

There are a number of new features and capabilities delivered in this release:

  • Support for OpenSLL v1.0.2 for the Digest, CBC, GCM, and RSA algorithms for improved cryptographic performance.
  • The ability to query running Java™ processes with our new Java process status tool (jps).
  • Improved platform support for pause-less garbage collection, with the addition of Linux® on POWER LE and AIX®.
  • The ability to write a Java dump file to STDOUT or STDERR as an alternative to writing to a file.
  • Better diagnostic information for Linux systems that implement control groups.
To find out more about these changes, read the OpenJ9 user documentation.

Eclipse OpenJ9 version 0.12.1 released

5th February 2019

We've released a minor update to version 0.12.0 due to issue 4530 , which affects OpenSSL cryptographic acceleration with the Digest algorithm. Support for the Digest algorithm is currently turned off.

Eclipse OpenJ9 V0.12.0 contains a number of improvements and new benefits. Here are the highlights:

Support for macOS®

This release adds support for OpenJDK 8 with OpenJ9 on the 64-bit macOS platform.

Extended support for pause-less garbage collection

Concurrent scavenge mode is now available on 64-bit Windows platforms. Support for 64-bit Linux x86 platforms is now extended for applications that require large heap (non-compressed references) VMs.

Improved cryptographic performance for the RSA algorithm.

OpenSSL 1.1.x support is now available for the RSA algorithm, in addition to Digest, CBC, and GCM. In our tests, we measured a 2-3× increase in RSA performance.

OpenJ9 performance gets better and better:

  • Improvements to AOT-compiled code during startup processing, which generates 10% startup time savings in AOT warm runs.
  • Improved density of AOT-compiled code in the shared classes cache by reducing the number of duplicated validation records. This change allows more AOT-compiled code to be stored, with faster load times.
  • 2× performance improvement when cloning arrays.

Documentation changes

We are now hosting two sets of user documentation:

If you are building OpenJDK with OpenJ9 against the latest OpenJ9 code base, any new features and changes can be found in the draft documentation.

You can read more about the changes in this release in our user documentation.

Eclipse OpenJ9 version 0.11.0 released

22nd October 2018

Our latest release of Eclipse OpenJ9 is now complete and comes with extended support and performance benefits:

Support for the macOS® platform

OpenJDK with OpenJ9 is now available on macOS. Early builds of OpenJDK 11 with OpenJ9 are now available at the AdoptOpenJDK project , with OpenJDK 8 coming soon.

Improved cryptographic performance with support for OpenSSL

OpenJ9 now supports OpenSSL v1.1.x for native cryptographic operations on OpenJDK 8, providing performance improvements over the default OpenJDK 8 cryptographic implementation. On x86 Linux, we measured up to a 15x improvement on encrypt and decrypt operations for the GCM and CBC algorithms compared to the default implementation.

Improved performance of AOT compiled code

Ahead-Of-Time (AOT) compiled code is ideal for using at startup time, but it is not as fast as JIT-compiled code from a throughput perspective. In this release, we have introduced an improved AOT implementation, with better throughput that bridges up to half the performance delta on x86-64 platforms compared to JIT-compiled code. At the moment, this new AOT implementation can be invoked under the -Xtune:virtualized option. There are three potential areas of improvement; (i) better startup time (because AOT code runs a lot during the startup phase), (ii) faster ramp-up time (where AOT is being used more aggressively under -Xtune:virtualized), and (iii) better throughput (for applications that are running lots of AOT code during steady state).

Memory optimizations for applications that run in containers

We recently added some intelligence to make OpenJ9 "container-aware", which allows it to make informed decisions about the size of your Java heap if you run your application in a container. Since applications are typically run on their own in a container and do not need to compete for memory, the JVM allocates a larger proportion of memory for the Java heap. With more container memory available, the JIT compiler can work harder, improving the ramp up time for applications. Conversely, if we do not have as much container memory available, the JIT compiler can reduce its memory usage to fit within the container limits. Due to good performance results and positive feedback, we've now enabled this feature by default.

Linux x86 support for our "pause-less" GC mode for response-time sensitive, large heap applications

We've now extended support to Linux 64-bit compressed references OpenJ9 builds for this innovative GC mode (-Xgc:concurrentScavenge) that runs concurrently with Java application threads. In this mode, the garbage collector is able to relocate objects while application threads are running, thereby reducing the "stop-the-world" application pause time needed to reclaim memory on the Java heap. Shorter pause times mean faster response times. So if you're running an app that requires a large Java heap but depends on fast response-times, why not try it out?

Can't wait to take advantage of Eclipse OpenJ9 0.11.0?

OpenJDK8 with OpenJ9 OpenJDK11 with OpenJ9

To read more about the changes in this release, head over to our user documentation.

Eclipse OpenJ9 version 0.10.0 released

3rd October 2018

Eclipse OpenJ9 version 0.10.0 adds support for OpenJDK version 11. All the testing we've done so far proves that builds are compatible with OpenJDK 11 and builds are now available at AdoptOpenJDK .

To learn more about our release strategy, plus our supported architectures and operating systems, see Supported environments .

To help users adopt OpenJ9 we have been busy adding compatibility for a number of HotSpot options. We are also writing content for the user documentation to help you compare HotSpot and OpenJ9 non-standard options and garbage collection policies. So if you haven't already tried an OpenJDK with OpenJ9 or you've stumbled into problems because command-line options you are familiar with are not recognised, we're working hard to improve the experience. If you have a migration problem, please help us out by posting details in a GitHub issue .

To read about other enhancements and notable changes in this release, see our What's new topic.

Eclipse OpenJ9 version 0.9.0 released

15th August 2018

We're pleased to announce the release of Eclipse OpenJ9 version 0.9.0.

V0.9.0 adds support for OpenJDK 10 builds, OpenJDK 8 Windows 32-bit builds, and OpenJDK large heap builds that support Java heap sizes > 57 GB. Work is underway to make these builds available at AdoptOpenJDK . If you want a large heap binary for a platform other than OpenJDK 8 Linux x64, you can easily build one by following our detailed build instructions. To learn more about our release strategy, plus our supported architectures and operating systems, see Supported environments .

Version 0.9.0 also includes some great progress to make the JVM more container-aware. When OpenJ9 is running inside a container, checks for memory availability and subsequent Java heap allocation now reflect limits that are imposed on the container. You can read more about our enhancement plans and progress around container technology in Eclipse OpenJ9 in Containers.

We are also introducing a new garbage collection policy mode to implement JEP 318 . When this policy is enabled (-Xgcpolicy:nogc or -XX:+UseNoGC), the Java object heap is expanded in the normal way until the limit is reached, but memory is not reclaimed through garbage collection. This mode is ideal for short-lived applications and useful for test purposes.

To read about other enhancements and notable changes in this release, see our What's new topic.

If you are interested in trying the OpenJDK 8 Windows binaries, we've run some Eclipse performance tests to compare OpenJ9 and the HotSpot JVM. Our results indicate that OpenJ9 is 43% faster and uses 42% less memory. Read more about these amazing results in Eclipse OpenJ9; a bake off on Windows. In fact, the results are so impressive that the Eclipse Foundation have decided to bundle OpenJ9 with a future release of the Eclipse IDE.

On a final note, user documentation is now available to support the configuration, tuning, and diagnosis of JDKs that contain the OpenJ9 JVM. Expect the content here to grow over time as more information is written about our JIT compiler, garbage collectors, shared classes cache implementation, and diagnostic capabilities.

Introducing the OpenJ9 blog

11th May 2018

We've just started up a blog to share interesting insights and information about the Eclipse OpenJ9 project. Over the coming weeks our developers are promising lots of exciting articles that will lift the lid on many of the great features and capabilities of OpenJ9.

Why not hop over and check it out!

What are others saying about OpenJ9?

20th March 2018

We've been keeping track of what people are saying about OpenJ9, and you'll find several interesting articles and blogs listed on our Resources page.

We're on the lookout for more, so if you spot a mention of OpenJ9 (or you've written an article yourself!), please tell us by raising an issue so we can share it with everyone.

New performance tests with OpenJDK™ 8

19th March 2018

We've already demonstrated the performance advantages of OpenJDK 9 with OpenJ9, but you might be wondering what you get with OpenJDK 8. So we have taken the opportunity to re-evaluate the performance of OpenJ9 when running OpenJDK 8, using the same metrics as we used when we tested OpenJDK 9.

OpenJDK 8 with OpenJ9 resulted in a 42% faster startup and a footprint at least 60% smaller, than OpenJDK 8 with HotSpot: results that are very much in line with our previous tests.

You can see the full range of tests and their results on the updated Performance page.

Eclipse OpenJ9 version 0.8.0 released

14th March 2018

We're pleased to announce that we have just released our first official version of Eclipse OpenJ9.

Version 0.8.0 supports OpenJ9 embedded in an OpenJDK version 8 binary on all platforms available at AdoptOpenJDK. If you haven't given it a test drive yet, why not download a build and let us know what you think.

Our release plan provides more information about the scope of this release, with any current limitations detailed in the release notes.

Come hangout with the OpenJ9 community

1st February 2018

Our regular community hangouts are a great place to meet the team and find out what is going on in the OpenJ9 project. Everyone is welcome and the agenda is pretty flexible. Generally we discuss hot topics like release plans, issues, ideas, and working processes, but we're open to requests. If you'd like to get involved at some level, why not come along? Maybe you have some suggestions, or maybe you'd like to provide some feedback about your experiences using an OpenJDK with OpenJ9. If you just want to come and listen, well that's fine too!

Schedules, agendas, minutes, and recordings are posted in the OpenJ9 slack workspace, in the #planning channel.

To update your Google calendar: add OpenJ9 hangouts.

To join slack: request an invitation.

Join us on slack

5th December 2017

We're pleased to announce the introduction of a new slack workspace, which we hope will become a popular medium for collaborating with the OpenJ9 project team in addition to our Eclipse mailing list. Whether you have questions to ask or experiences to share, we'd love to hear from you.

Join slack: request an invitation.

Eclipse OpenJ9 for Java 8

22nd November 2017

Over the last couple of months, we've been talking about OpenJ9 with pretty much everyone who'd listen to us. People have told us that OpenJ9 for Java 9 is a great achievement, but many users and developers aren't ready to step up to Java 9 just yet. The most popular request we've heard is to combine Eclipse OpenJ9 with a Java 8 JDK so that it can be used in day-to-day development and production environments.

We heard that feedback loud and clear, and the Eclipse OpenJ9 community has been working hard to make it a reality!

The OpenJ9 project is proud to announce that you can now build OpenJDK8 with Eclipse OpenJ9. Downloadable binaries are already available at the AdoptOpenJDK project:

Download binaries here

If you want to build OpenJDK8 with OpenJ9 yourself, you can follow the instructions on our build page. Right now, you can build it for Linux on x86-64, ppc64le, s390x, and AIX. More platforms to follow!

Did we already tell you that the Eclipse OpenJ9 project uses a single code stream to implement the JVM across all supported Java releases, from Java 8 to Java 9 and beyond? That means users should get the same excellent performance, features, and new processor support from OpenJ9 no matter which Java level you're using to run your applications.

Interested in what performance you can expect for OpenJDK8 with OpenJ9? The data is not on our website at the moment, but for applications we've tried, OpenJDK8 with OpenJ9 performs the same or better than OpenJDK9 with OpenJ9. If you haven't seen the impressive results for OpenJDK9 yet, pop over to our performance page.

We're really excited to bring you Java 8 support, and we hope you'll take it for a test drive. We think it will be a great experience for you. Good or bad, let us know how it goes! You can connect with us via GitHub issues or on stackoverflow using the #OpenJ9 tag. We look forward to hearing from you!

The OpenJ9 project leads: Mark, Dan, Peter, and Jonathan