Latest Graal and AArch64 WTF?

[Doug Simon]

Hi Andrew,

Does the "JVMCI-jars-only" work-around described at http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html not work for you? The original mail in that thread provides some background as to why the build change was made.

In terms of making Graal not require a JVMCI JDK8 to build, one would need to factor out all code using API specific to a JDK version. For each body of such code, you'd have a "placeholder" source file specifying its API and overlays for each JDK version. Currently, we collapse the JDK8 overlay into the placeholder. As a concrete example of what I mean, today we have:

src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java
src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java

Where the first file specifies the API for GraalServices as well as its JDK8 implementation.

We need to move to this instead:

src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java
src/org.graalvm.compiler.serviceprovider.jdk8/src/org/graalvm/compiler/serviceprovider/GraalServices.java
src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java

Where the first file specifies only the API and all its methods simply throw some exception.

In addition to the Java code changes, you'd also need to modify mx to consider JDK8 overlays (until now, overlay support is mostly in the JDK9+ parts of mx).

-Doug


> On 26 Jul 2018, at 12:29, Andrew Dinn <adinn at redhat.com> wrote:
> 
> The latest graalvm repos on github include a helpful source tree for
> building a JVMCI-enabled jdk8u:
> 
>  https://github.com/graalvm/graal-jvmci-8
> 
> and Oracle even offer a helpful, pre-built x86_64 download.
> 
> This specific repo exists because -- for somewhat unaccountable (or at
> least unaccounted) reasons -- the mx scripts demand that you have a jdk8
> available to execute some part of the build process /even if/ you are
> trying to build the Graal compiler using jdk11 (or the jdk dev tree) for
> use with jdk11 (or, respectively, the jdk dev tree).
> 
> So, some version of the JVCMI code, lots of tooling patches (e.g. to the
> IdealGraphVisualizer) and a bunch of hotspot shared and CPU changes have
> been munged into a variant of the jdk8u hotspot src tree embedded in the
> above repo.
> 
> Unfortunately, a big problem with this change to the build process is
> that this hotspot source tree is based on the upstream jdk8u repo and
> not on Red Hat's downstream jdk8u-aarch64 or jdk8u-shenandoah repos (the
> ones that include the AArch64 port of OpenJDK used by all Linux+AArch64
> releases).
> 
> As a consequence, it is now /impossible/ to build the Graal compiler on
> AArch64 without first porting all that hotspot gubbins into our
> downstream repo.
> 
> Let me just restate that for emphasis: it is now /impossible/ to build,
> maintain, fix or in any way extend or improve the functionality of the
> Graal compiler on AArch64. The AArch64 bits are rotting as regards use
> on jdk8 or any other, later jdk.
> 
> That makes the decision to make this change to the build system a rather
> bad one, in my opinion. I say that because having looked at the
> differences introduced into the above repo by diffing it with the
> corresponding jdk8u tree I am pretty sure that porting the changes it
> includes to our jdk8u-aarch64 tree is a non-starter.
> 
> If the jdk8 back-porting effort had initially been done using our
> AArch64 tree this decision might not have been so awful, however
> distasteful I find the idea that you have to use two different JDKs to
> build Graal for a given target JDK.
> 
> Given the current impasse as regards progress with AArch64 I think it is
> imperative that some way is found of building the Graal compiler using
> jdk11+ for target jdk11+ that does not also require a tweaked jdk8
> compiler. I would like to fix whatever is needed in the Graal or JVMCI
> code or the mx scripts to make that possible.
> 
> So, could someone provide the background rationale for this change and
> why it was seen as better than fixing the Graal, JVMCI and/or mx code?
> Does anyone have any other information that might help scope what would
> need to be changed in Graal, JVMCI or mx in order to allow JDK11 to
> generate a JDK11 compatible Graal compiler?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander