RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5]

[Timofei Pushkin]

On Thu, 10 Apr 2025 16:01:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Currently we have some restrictions if`-Djava.system.class.loader=` is specified
>> 
>> - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286
>> - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886
>> 
>> I think we should extend this limitation further (in a separate issue)
>> 
>> - At dump time, dump only boot classes (no platform, system or unregistered)
>> - At run time, load only boot classes (no platform, system or unregistered)
>> 
>> I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315)
>
> In the current JDK (with or without this patch), in your scenario, I think the name "S" will be printed twice with two different IDs. If a Child class named "C" is loaded by a custom loader, it will refer to one of the IDs. Depending on the order of loading, it might refer to the first or the second ID.
> 
> During dump time, we will try to load this class twice, but both attempts will result in the same class (defined by the user-defined system class loader). When resolving the unregistered class, using either ID will give you the correct super class ...
> 
> Anyway, this seems too fragile. I think we should fix [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating this patch. Or, maybe we can include the fixes of that bug in this PR as well (and then close that bug as a duplicate of this one). What do you think?

In my scenario I actually meant that <S, AppL> is in the class list while <S, SysL> is not but it doesn't matter much, the incorrect one will be loaded any way.

Since the new implementation will behave the same as the existing one in this aspect I think it is OK to fix JDK-8354315 separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042346769