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

[Thomas Stuefe]

On Tue, 1 Apr 2025 17:37:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

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

This PR only moves code around, at least here. I am unsure why this code uses next_link. My understanding from reading the code and from Ioi's explanation is that LambdaProxyClassDictionary re-uses the next_link linking mechanism for linking CDS proxy classes together before they are loaded; so they are not yet part of the CLDG and this use does not conflict with the use of next_link in the CLDG. 

I may be wrong though and am happy to be corrected.

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

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