RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

> On Sep 13, 2015, at 11:35 PM, Erik Österlund <erik.osterlund at lnu.se> wrote:
> 
> Hi Christian,
> 
> It is very interesting to expose a Java-level API for the compilers, and it makes me happy to read about it.
> 
> Out of curiosity, I’m wondering two things.
> 
> 1. Are there intentions to target release builds eventually, so library implementors can use custom JITs, and not just for experimenting?

The JEP is targeted for JDK 9 so this feature should be (if nothing serious goes wrong) in JDK 9 GA.  The JVMCI will be hidden behind experimental flags but you can turn it on any time in Oracle JDK product builds.

> 
> 2. In that case, I wonder what impact these potential library JITs will have on the GC interface/ABI. 
> I assume it is intended that the already implemented GCs will be used by this new JIT. 
> In that case, I assume there needs to be some kind of interface between the JIT and GC.
> 
> In particular what I am thinking about is exposing some current GC ABI assumptions including what GC barriers there could be for memory accesses (e.g. barriers only for references, not primitives), then never being able to change the such assumptions further down the road because third party libraries with custom JITs suddenly depend on previously valid ABI and compiler details that have to be set in stone for compatibility reasons.
> 
> Any comments on this? Is this an issue?

This API is for HotSpot and all JIT compilers using this interface must follow the rules the HotSpot GCs have.  If your JIT supports Parallel GC you have implement whatever barriers Parallel requires.  Same for CMS and G1.

There is no "GC interface” because there is nothing to be queried really.  The type of barrier code JIT compilers need to emit for the different GCs is pre-defined and might also change (for whatever reason).  In our current world if something changes we have to change C1 and C2 at the same time.  External JIT compilers will definitely lag behind but in order to work properly they have to be updated as well.

I hope this answers your question.

> 
> Thanks,
> /Erik
> 
>> On 14 Sep 2015, at 09:24, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> The JEP itself can be found here:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8062493 <https://bugs.openjdk.java.net/browse/JDK-8062493>
>> 
>> Here are the webrevs:
>> 
>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>> 
>> The change has already undergone a few iterations of internal review by different people of different teams.  Most comments and suggestions were handled accordingly.  Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8134994 <https://bugs.openjdk.java.net/browse/JDK-8134994>
>> 
>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP.
>> 
>> The integration will happen under the bug number:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8136421 <https://bugs.openjdk.java.net/browse/JDK-8136421>
>> 
>