RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive

[Thomas Stuefe]

On Mon, 31 Mar 2025 15:41:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please consider.
>> 
>> This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I  need this mechanism for some future GC work.
>> 
>> Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag.
>> 
>> It also adds a new, rather basic, gtest.
>> 
>> Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that.
>> 
>> ----
>> 
>> Testing:
>> - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes
>> - I ran all runtime/cds tests on Linux x64
>> - GHAs
>
> src/hotspot/share/cds/lambdaProxyClassDictionary.cpp line 93:
> 
>> 91:     while (k != nullptr) {
>> 92:       cl->do_klass(k);
>> 93:       k = k->next_link();
> 
> When do you plan to use this API? `k->next_link()` will change if `k` has been loaded in runtime, so you can no longer use it to find other archived lambda proxy classes.

I will call this after the CDS archive has been mapped, at the same time as PrintSharedArchiveAndExit would have been called. But I would like this function to work at any time. 

But above all, it is very paramount that this technique finds me all classes that are in this archive and not loaded via the normal dynamic class loading path. I also need this method to work reliably also with any improvements ongoing (e.g. JEP 483). Is there a better way?

Looking into the code, I see that this method (scanning classes via Klass::next_link) is also used to implement LambdaProxyClassArchive.find()/LambdaProxyClassDictionary::find_lambda_proxy_class. Which uses the linked list precomputed with AdjustLambdaProxyClassInfo. It uses Klass::next_link, but that is used by the CLDG to tie classes of the same loader together. How does this work? Would LambdaProxyClassArchive.find() (and thus LambdaMetaFactory.metafactory()) not have the same problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2022229593