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

[Coleen Phillimore]

On Tue, 1 Apr 2025 07:03:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.
>
> No, not yet, though I have talked with many people about this, to positive feedback. I will put this in writing soon.
> 
> The gist of this is: I have a prototype called "KLUT" (KlassLookupTable), which pre-computes a 32-bit token per Klass and puts that into a lookup table with the narrowKlass as index (remember, for COH, narrowKlass is really an index, 1 2 3 4 5).
> 
> That token contains a condensed subset of information from Klass. The token is then used to get type information for oop iteration in GC. That avoids having to access Klass during GC, in fact, we don't even need to decode the nKlass. 
> 
> All of that drastically reduces cache misses during GC, since we don't have to pick type information from a very sparse Klass but load a 32-bit value from a very condensed table. It practically takes out type information loading as a source of cache misses from the equation.
> 
> To get the fullest benefit from this optimization, I pre-generate these tokens on Class loading. I could calculate them on demand, too, but that would add another branch into the hot path of oop iteration. I would rather avoid that.
> 
> So, I need to ensure these tokens are generated for every Klass for which I will find objects in the heap. Hence this PR.

I'm confused by this.  next_link is the next link in the ClassLoaderData klasses list.  Why is this in LambdaProxyClassDictionary?

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

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