RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v6]

[Quan Anh Mai]

On Wed, 9 Oct 2024 05:53:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.
>
> On 8 Oct 2024, at 4:07, Andrew Haley wrote:
> 
>> On 9/10/24 12:42, Coleen Phillimore wrote:
>>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>>
>> I'm a bit concerned about this one.
>>
>> I'm working on megamorphic dispatch, and a uniform representation of
>> compressed class pointers allows me to squeeze klass+offset into a
>> single 64-bit word. This in turn allows fast and simple method
>> lookups. I need, at least, to be able to use compressed interface
>> pointers. If interfaces are "somewhere else", and thus incompressible,
>> I can't do what I need to do.
> 
> This is an interesting use of compressed klass pointers.
> 
> It looks like the compression needs to be partial, down to about 32 bits.
> 
> A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.
> 
> So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.
> 
> (Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn’t exactly true.)
> 
>> … If, however, klass and non-klass
>> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
>> rather use compressed klass pointers without having to decode them.
> 
> The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven’t needed to invent.)
> 
>> All I need is a way to represent interface pointers in a compact way
>> in lookup tables, and to be able to get from compressed class pointers
>> to the address. As long as interface pointers are in a 32-bit range
>> and there's a fast way to get from compressed class to address that's
>> OK.

@theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help?

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401380082