On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon <dnsi...@openjdk.org> 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.
>
> Doug Simon has updated the pull request incrementally with four additional
> commits since the last revision:
>
> - formatting to avoid very long lines [skip ci]
> - removed debug code [skip ci]
> - clarify Properties filtering [skip ci]
> - remove debug code [skip ci]
src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:
> 126: // Try create with reflection first.
> 127: try {
> 128: Class<?> cls = Class.forName(className);
A question about the Class.forName usage here. Class.forName uses the defining
class loader of the current class so I'm wondering if the exceptions to be
decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is
defined to the boot loader so this code hasn't really changed, it's just "new"
to java.base in this PR.
-------------
PR: https://git.openjdk.org/jdk/pull/11513
