Developing Graal now requires JDK 8

[Doug Simon]

> On 26 Jan 2017, at 23:06, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 26/01/2017 19:57, Doug Simon wrote:
> 
>> Hi jigsaw experts,
>> 
>> As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don’t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we’d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler).
>> 
>> To help me understand if there’s an existing solution I’m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String:
>> 
>>     String truncate(int trailingCharsToChop) { ... }
>> 
>> How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file?
>> 
>> What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API?
> 
> This should do it:
> 
> javac -Xmodule:java.base -d patch String.java
> 
> // compile module against the patched java.base
> javac --patch-module java.base=patch …

But --patch-module doesn’t allow you to replace module-info.class. Consider separate javac compilations, A and B where A compiles the core Graal packages and B compiles subsequent Graal packages that depend on the packages in compilation A. Since the jdk.vm.compiler module-info.class in the JDK does not publicly export the packages in A, compilation B will fail with access violations. Even if --patch-module could replace module-info.class, the way we compile the packages in Graal means we’d need to synthesize intermediate versions of module-info.class, representing the packages currently available on the argument to --patch-module. All this reenforces my feeling that one simply cannot compose a module from separate javac compilations when that module is already in the JDK and visible to javac. Hence the need for an option like --exclude-modules.

> 
> // run with the patched java.base
> java --patch-module java.base=patch …


> 
>> Note that this constraint is particular painful for the AArch64 Graal port. The version of JDK 8 we use[2] includes a port of JVMCI (that we hope to get into an official JDK 8u backport). However, there is no such bundle for AArch64 so hacky workarounds are required[3][4].
>> 
>> Any light you can shed on how we can develop Graal with (only) a JDK >8 would be much appreciated.
>> 
> It seems to me that you really want to override jdk.vm.compiler and maybe we should explore again making this an upgradeable module.

Would that help make it possible to do multi-javac-compilation construction of the upgradeable module as described above?

-Doug