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

[Andrew Haley]

On Wed, 9 Oct 2024 09:00:06 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 10/9/24 06:53, John Rose wrote:
> 
>  > It looks like the compression needs to be partial, down to about 32 bits.
> 
> Yes, that's true. Slightly fewer bits would be nice, for tags.
> 
>  > 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.
> 
> I see, I think.
> 
> Simply keeping all of metadata in a single 32-bit range would be very
> useful. We could have instantiable Klasses in one region, followed by
> non-instantiable Klasses.
> 
>  > (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.)
> 
>  > 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.)
> 
> While I've now thought of a way to encode Klass pointers that doesn't
> need them all to be in the same 32-bit range, it may well be very
> useful in other contexts to ensure that they will be.
> 
> Maybe we could reduce the footprint of Klass instances. Right now,
> though, my invokeinterface prototypes *increase* the size of Klass
> instances, so I really want to have the possibility of using
> compressed metadata pointers.
> 
> For what it's worth, I'm relieved that we're not yet making Klass
> pointers a table index. Another chained load in the path of method
> dispatch, at a time when I'm trying to get rid of chained loads, would
> be a Bad Thing for me.
> 
> -- 
> 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

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

Of course that is possible, but it add complexity; and my goal is reducing complexity.

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

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