Summary
-------

Develop a Java based JVM compiler interface (JVMCI) enabling a compiler written in Java to be used by the JVM as a dynamic compiler.

Goals
-----

 - Allow a Java component programmed against the JVMCI to be loaded at runtime and used by the JVM���s compile broker.

 - Allow a Java component programmed against the JVMCI to be loaded at runtime and used by trusted Java code
   to install machine code in the JVM that can be called via a Java reference to the installed code.

Non-Goals
---------

 - Integration of a dynamic compiler (such as Graal) based on JVMCI.

Success Metrics
---------------

 - The ability of a JVMCI based dynamic compiler to run on the unmodified JVM. The performance of compiler and
   its generated code are not of high concern since JVMCI will be an experimental feature in JDK 9 and as such
   only enabled by specifying certain flags on the command line.

Motivation
----------

An optimizing compiler is a complex piece of software that benefits greatly from the features provided by Java
such as automatic memory management, exception handling, synchronization, excellent (and free) IDEs, excellent
unit testing support and runtime extensibility via service loaders just to name a few. In addition,
a compiler does not require the low-level language features required by many other JVM subsystems such as the
bytecode interpreter and garbage collector. These observations strongly suggest that writing a JVM compiler in
Java should allow production of a high quality compiler that will be easier to maintain and improve than existing
compilers developed in C or C++. JVMCI provides the API necessary to demonstrate and experiment with this potential.

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

The JVMCI API will be composed of mechanisms for:

 - Accessing VM data structures required by an optimizing bytecode-to-machine-code compiler
   such as classes, fields, methods, profiling information etc.
 - Installing compiled code along with all the metadata required by the JVM for managing
   compiled code such as GC maps and information to support deoptimization.
 - Plugging into the JVM's compilation system to handle servicing JVM requests to produce machine code for methods.

An excellent demonstration of using JVMCI to write and deploy a high performance compiler in the JVM is
provided by [Graal][1] which has demonstrated peak performance on par with C2 across a wide range of benchmarks.

Alternatives
------------

There are no existing alternatives for a Java based compiler that is usable as a dynamic compiler in the JVM.

Testing
-------

The JVMCI implementation includes an extensive set of unit tests for the parts of the API exposed to a compiler
developer as well as white box tests for internal parts that makes calls into the VM to implement the public parts.

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

A Java API that allows VM internals to be accessed and compiled code to be installed and executed presents an
obvious security risk. In JDK8 (where JVMCI was first prototyped and is still co-developed along with the JDK 9
port), the JVMCI API was hidden from untrusted code by loading it with a class loader inaccessible to anything 
but code on the boot class path. In JDK 9, the intention is to use access controls that are part of
the Module System [JEP 261][2] to prevent untrusted code from being able to use JVMCI. JVMCI needs to be as secured
as the Unsafe class is.

JVMCI will be experimental in JDK 9 and such will require extra command line options to enable it. For example:

    -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=<name of compiler>

Making JVMCI experimental allows for extensive experimentation while mitigating any risk to JVM customers.

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

As mentioned above, JVMCI is dependent on the access controls in [JEP 261][2] to isolate JVMCI from untrusted code.

[1]: https://openjdk.java.net/projects/graal/
[2]: https://openjdk.java.net/jeps/261