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

[Andrew Haley]

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> 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 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. 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.

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.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

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