[openjdk/jdk] 8338526: Don't store abstract and interface Klasses in class metaspace (PR #19157)

[Andrew Haley]

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