Summary
-------

Java based VM compiler interface (JVMCI), [JEP-243](http://openjdk.java.net/jeps/243) should support JVMCI based Just-In-Time Compiler (such as Graal) which is Ahead-Of-Time compiled into a native shared library.

Goals
-----

JVMCI should work with JVMCI based Compiler in current form, as Java application in class files, and in native shared library form. This allows for easier development of such Compiler (debugging with Java IDEs is easier than debugging with gdb).

JVMCI should allow to run JVMCI Compiler in both forms at the same time in the same VM instance. This will be particularly important in the process of replacing C1 and C2 with Graal. For example, Graal in shared library form as the first tier JIT and Graal in class files as the top tier JIT.

Description
-----------

It should be possible to deploy JVMCI based compiler (such as Graal)  as an AOT compiled shared library. This can offers benefits including:

* fast startup
* compile time similar to native compilers
* memory usage disjoint from the application Java heap
* no profile pollution of JDK code used by the application

One means of achieving this is to produce 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](https://docs.oracle.com/javase/10/docs/specs/jni/invocation.html)
* Enhancements to JVMCI to support both producing and using AOT compiled shared library.

JVMCI C++ code would need to operate on JVMCI Java objects in 2 different heaps - the HotSpot heap and the shared library heap. We'll introduce JVMCIObject, a wrapper that abstracts over whether a Java object is a HotSpot oop or a JNI jobject.

The JVMCIRuntime C++ class would be converted to have non-static methods and be instantiated one instance per HotSpotJVMCIRutime Java object in each heap. It would include methods that allow invoking JVMCI Java methods, abstracting over whether calling into the HotSpot or shared library runtime.

Care must be taken to handle cross-runtime-heap objects references.

Testing
-------

There are no additional testing required for this JEP. We just need to pass existing JDK regression and performance testing which uses JVMCI. Additional testing will be added for once Graal is modified to use the JVMCI extensions added by this JEP.

Risks and Assumptions
---------------------

These JVMCI changes are required for deploying Graal as an AOT compiled shared library (i.e. libgraal).

Dependencies
-----------

Future libgraal JEP depends on this JEP.