Rename jdk.internal.vm.compiler to jdk.compiler.graal

[Foivos Zakkak]

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
> <https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20231020/3893beed/attachment-0001.htm>