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
>>
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
>>
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
>
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
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
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
>
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
>>
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
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
>>
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
>
>
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
>>
> 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
14 matches
Mail list logo
