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

[coleen.phillimore at oracle.com]

Hi Andrew, I was on vacation and this isn't a complete answer but some 
points.

On 10/9/24 5:00 AM, Andrew Haley wrote:
> 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.

The important aspect of class metaspace area is that it's a fixed size 
and this is also its problem. It's not location in the area, it's that 
the area is fixed.  There's piles of code and math to map the class 
metaspace and deal with its interaction with CDS (and there's also bug 
JDK-8340212 <https://bugs.openjdk.org/browse/JDK-8340212> affecting 
Lilliput).  This idea would add more code to that. Also, adding more 
code to metaspace to direct placement location in the class metaspace is 
code I don't wish to imagine.

>
> > (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.

I suppose that's good you don't need the interface pointers to be in the 
same memory area as the klass pointers.  There may be a performance bug 
with moving them so we might have to undo part of this change.  The goal 
was to have the generated classes not be in class metaspace and 
interfaces came for the ride.  But it was never a design to have 
Metaspace pointers in Metaspace be compressed and a lot of CDS and code 
throughout the JVM expects to just be able to use pointers without 
adjustment.

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

Increasing the size of Klass instances is painful.  Make your new thing 
something that Klass points to. It doesn't matter how much memory you 
use in non-class metaspace.

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

Sorry about this Bad Thing but we are investigating exactly how to do 
this and not lose performance.  We haven't given up on this idea because 
of aforementioned piles of code we don't like to maintain, and the 
allure of not having the special "Class Metaspace" for each 
ClassLoaderData anymore.

Coleen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241014/4f08c4d5/attachment.htm>