On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon wrote:
> You need to check if class is already loaded by trying findLoadedClass first.
Thanks @xxDark . I knew it should work. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908961416
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon wrote:
> You're right. I had forgotten the intricacies of class loader delegation. The
> only hard constraint on loading a class in multiple loaders is that `java.*`
> classes [must (only) be loaded by the boot
> loader](https://github.com/openjdk/j
On Wed, 24 Jan 2024 12:16:44 GMT, xxDark wrote:
> You need to check if class is already loaded by trying findLoadedClass first.
You're right. I had forgotten the intricacies of class loader delegation. The
only hard constraint on loading a class in multiple loaders is that `java.*`
classes [mu
On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon wrote:
> > I'm still puzzled by the need to do this as any non-delegating classloader
> > would have allowed this even if JVMCI were loaded by the bootloader.
>
> As far as I understand, even a non-delegating classloader cannot redefine a
> class lo
On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon wrote:
> As far as I understand, even a non-delegating classloader cannot redefine a
> class loaded by the boot loader. I modified the test to show this and get:
>
> ```
> java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted
> d
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Wed, 24 Jan 2024 08:46:08 GMT, Doug Simon wrote:
>> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54:
>>
>>> 52:
>>> 53: ClassLoader pcl = ClassLoader.getPlatformClassLoader();
>>> 54: URLClassLoader ucl = new URLClassLoader(cp, null);
>>
>> I am missing s
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Tue, 23 Jan 2024 17:00:20 GMT, xxDark wrote:
> There is zero reason to do this. Passing `null` as parent class loader would
> suffice as boot loader just uses `findBootstrapClassOrNull` in
> `JavaLangAccess` either way.
Right, using `null` does the same thing. In the final version will use
On Wed, 24 Jan 2024 06:11:30 GMT, David Holmes wrote:
> I'm still puzzled by the need to do this as any non-delegating classloader
> would have allowed this even if JVMCI were loaded by the bootloader.
As far as I understand, even a non-delegating classloader cannot redefine a
class loaded by
On Wed, 24 Jan 2024 06:07:55 GMT, David Holmes wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use null to denote boot class loader as delegation parent
>
> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Tue, 23 Jan 2024 17:00:20 GMT, xxDark wrote:
> Passing `null` as parent class loader would suffice as boot loader just uses
> `findBootstrapClassOrNull` in `JavaLangAccess` either way
Thanks! I've simplified the test accordingly:
1642276ea22a5d789e01a5ecb1059d8c5c8be284
-
PR C
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
> class loader instead of the boot class loader. This allows Native Image to
> load a version of JVMCI different than the version on top of which Native
> Image is running. This capability is demonstrated and tested by
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote:
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
> class loader instead of the boot class loader. This allows Native Image to
> load a version of JVMCI different than the version on top of which Native
> Image is
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote:
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
> class loader instead of the boot class loader. This allows Native Image to
> load a version of JVMCI different than the version on top of which Native
> Image is
This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
class loader instead of the boot class loader. This allows Native Image to load
a version of JVMCI different than the version on top of which Native Image is
running. This capability is demonstrated and tested by
`LoadA
19 matches
Mail list logo
