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

[Ioi Lam]

On Tue, 1 Apr 2025 06:30:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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?

Once the lambda proxy class is loaded, it's removed from the LambdaProxyClassDictionary, so we won't find it (and try to load it again). This is intended.

Did you file an RFE for that explains what you intend to do with such an iterator in the future? We should understand the requirements before making this change.

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

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