Keeping up with Java: JEP draft proposes JVMCI based just-in-time compiler

© Shutterstock /Supavadee

Time to keep up with the developments happening in Java and in the potential future of the JDK. Let’s take a look at this newly added JEP draft: JVMCI based just-in-time compiler pre-compiled as shared library. What goals for Java does it propose?

Open source collaboration on Java continues, with new additions and suggestions from the community on how the future of Java should progress. What changes are currently up for discussion?

Meet the latest JEP draft: JVMCI based JIT Compiler pre-compiled as shared library.

Read along to find out its proposed goals and potential benefits.

JEP draft goals

Created on May 2, 2019 the draft proposes support JVMCI based Just-In-Time Compiler (such as Graal) which is Ahead-Of-Time compiled into a native shared library.

SEE ALSO: The fight for performance – Is reactive programming the right approach?

From OpenJDK, here’s this JEP’s goals:

To replace native compilers in HotSpot (i.e., C1 and C2), JVMCI based Compiler should have the following characteristics:

  • fast startup
  • compile time similar to native compilers
  • memory usage disjoint from the application Java heap
  • bulk de-allocation of memory used during a single compilation
  • do not pollute profiling of JDK code used by the application.


How to achieve it?

What are the plans for tackling this draft JEP?

Vladimir Kozlov writes that “the best  way to achieve this is to compile such Compiler with SubstrateVM native-image tool into a shared library that HotSpot VM can interface with via JNI. This requires:

A technology by which JVMCI and Compiler can be compiled into a shared library that implements the JNI Invocation API
Enhancements to JVMCI to support both producing and using SVM compiled shared library.”

In order to achieve this, the following proposed new hotspot flags would also be added:

  • -XX:+UseJVMCINativeLibrary to load shared library from default location (in JDK directory)
  • -XX:JVMCILibPath=”path” to specify library location

For more information on the origin of this JEP draft, refer to the discussion that initially began Vladimir Kozlov’s proposal. Also, see more detail on the JDK bug system.

SEE ALSO: “In a Serverless world, sophisticated orchestration tools aren’t just nice-to-have, they’re non-negotiable”

Will we be seeing this draft again in the future, possibly in a new JDK as a new feature?

For the time being, we will follow along with this draft and keep an eye on what the JDK community thinks, changes it goes through, and how it progresses from here.

Inline Feedbacks
View all comments