On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon <[email protected]> wrote:
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to
> be dynamically loaded at runtime. Prior to this PR, this is not the case due
> to:
>
> * Code to copy system properties from the HotSpot heap into the libgraal
> heap. This is in
> `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and
> `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be
> moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap
> and vice versa. This code should be moved from
> `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to
> `java.base/jdk.internal.vm.VMSupport`.
>
> This PR makes the above changes. As a result, it's possible to build a JDK
> image that includes (and uses) libgraal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
src/hotspot/share/classfile/classLoader.cpp line 1419:
> 1417:
> 1418: // Returns true if jdk.internal.vm.ci is present on the file system.
> 1419: bool ClassLoader::has_jvmci_module() {
Would it be more useful to pass the module name so that the function tests if
the module is is in the run-time image so that ClassLoader doesn't need to know
the name "jdk.internal.vm.ci"?
-------------
PR: https://git.openjdk.org/jdk/pull/11513
