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

Tue Sep 15 07:25:12 UTC 2015

> On 14 Sep 2015, at 19:40, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Sep 13, 2015, at 11:35 PM, Erik Österlund <erik.osterlund at lnu.se <mailto: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.

Okay.

> 
>> 
>> 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.

Okay.

> 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 suspected as much. I was just worried that such a feature would make it increasingly difficult to make changes to e.g. GC barriers (for whatever reason). Before you had to change code in HotSpot components (C1, C2, interpreter, runtime) which is possible to deal with and you know if the JVM is fixed properly, code will run well in Java-land. But now you might have to change all third party compilers outside of the JVM as well, and in the worst case different libraries prefer different compilers that are automatically packaged and spread around like a plague into products using dependency tools like maven without the end-user even having a clue there are custom JIT-compilers packaged in their applications making lots of assumptions about JVM/GC internals.

The reason I am a bit worried is not just because it’s a hassle to change more compilers, but because I think the issue of the GC having a contract (implicit or explicit, same difference) with third party JITs in Java-land is a very similar issue as having a kernel with an ABI contract and code in user land relying on it. And in the same sense that this ABI locks kernel developers into corners because they cannot break user-space, I fear that we could be locked in as well for the very same reasons: that changing the implicit or explicit GC ABI contract to the JITs (which previously was a bit of hassle but doable) would suddenly break Java-land that has suddenly been infected with assumptions about JVM/GC internals. And we would then not be able to make improvements that break Java-land ABI assumptions, because every new release of Java has to be compatible with the previous releases so that code already written will continue to work.

I don’t know, maybe I’m a bit paranoid and overreacting. Maybe compilers will be very few in practice and shipped together with the JVM itself so they are guaranteed to be compatible, rather than spread out in libraries shipped with applications in very few carefully considered cases. And obviously this imaginary JIT apocalypse won’t happen as long as it’s an experimental flag. Just thought I’d share my point of view so that if an unbreakable Java-land ABI would pop up out of nowhere to constrain us, at least we thought about it, saw it coming and are fully aware of it.

> I hope this answers your question.

Yes it does, thank you!

Regards,
/Erik

> 
>> 
>> 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>