[External] : Re: Rename jdk.internal.vm.compiler to jdk.compiler.graal

[Douglas Simon]

Hi Foivos,

JVMCI is not a general API but has always been somewhat Graal specific. Project Galahad is demonstrating this strong coupling and taking the next logical step which is to move Graal into the JDK. At that point, we will strongly consider positioning JVMCI as JDK internal only.

Note that projects such as Tornado VM rely on Graal, not just JVMCI. Without this proposed change, these projects would no longer work with OpenJDK. I would recommend that any project wanting to develop a Java based compiler for OpenJDK, follow the pattern of Tornado VM and build on Graal instead of JVMCI.

-Doug

> On 20 Oct 2023, at 10:59, Foivos Zakkak <fzakkak at redhat.com> wrote:
> 
> Hi Doug,
> 
> On Thu, Oct 19, 2023 at 5:45 PM Douglas Simon <doug.simon at oracle.com> wrote:
> Adding galahad-dev at openjdk.org <mailto:galahad-dev at openjdk.org> to the thread.
> 
> > On 19 Oct 2023, at 16:38, Douglas Simon <doug.simon at oracle.com> wrote:
> > 
> > Within the last year or so, the Graal team have been making large structural changes to the Graal code base to prepare for merging it into OpenJDK under Project Galahad. It’s important to make these structural changes prior to merging the sources into OpenJDK as they typically involve changes to a large number of files. For example, all code in the jdk.internal.vm.compiler module was consolidated into a single source directory using the standard OpenJDK layout[1]. The commit for this change alone had 3,481 changed files, 317 additions and 1,759 deletions.
> > 
> > The above change could be made without any JDK changes. The next large change being undertaken is to rename the jdk.internal.vm.compiler module to jdk.compiler.graal[4]. Due to the way Java modules work, this does require a JDK change. The details are in https://bugs.openjdk.org/browse/JDK-8318027 but the core of the issue is that the service[2] by which HotSpot can request a Graal compilation is defined in JVMCI and implemented by Graal. Since this service is in the boot layer, it can only be implemented by a provider in the boot layer. This export currently targets jdk.internal.vm.compiler[3] and so the binding will fail once the Graal module is renamed. That is, an export to jdk.compiler.graal is required.
> > 
> 
> My concern is that this change means that moving forward any implementation of a compiler through JVMCI will have to provide the module jdk.compiler.graal instead of jdk.internal.vm.compiler. I am afraid this move is making JVMCI look Graal-specific which to my understanding was never the goal [1] despite its implementation being mostly Graal-driven in practice.
> 
> Has this been considered?
> 
> Thanks,
> 
> [1] https://openjdk.org/jeps/243  
> > The plan here is to replace the export to jdk.internal.vm.compiler with jdk.compiler.graal. This will allow OpenJDK binaries to keep working with the Graal code base post renaming. That is, it will allow the tip of Graal to continue working with the tip of OpenJDK, something that is important on the path to merging these 2 projects.
> > 
> > Please leave feedback by replying to this email or with comments on https://github.com/openjdk/jdk/pull/16189
> > 
> > -Doug
> > 
> > [1] https://github.com/oracle/graal/commit/8be56121aa31e7448b4adb0224ab2ac44095ed9b
> > [2] https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37
> > [3] https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.export to jdk.compiler.graalexport to jdk.compiler.graalci/share/classes/module-info.java#L28
> > [4] https://github.com/oracle/graal/pull/7621
> 
> 
> 
> 
> -- 
> Foivos Zakkak
> Senior Software Engineer, R&D Product Middleware
> Red Hat
> 7B4069D929BAAE91C0B3220A0846BFD103F04EA1