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

[Andrew Haley]

On 10/14/24 22:55, coleen.phillimore at oracle.com wrote:
 >
 > Hi Andrew, I was on vacation and this isn't a complete answer but some points.

Thanks.

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

OK, got that.

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

I see. I'll have a look at what I can do.

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

OK. I'll think on. Please bear in mind that I have the possibility of
shrinking the size of Klass instances, which I guess you'd like too.
We're not working in opposition.

Some background to what I'm trying to do:

The HotSpot tradition seems to have been to avoid megamorphic dispatch
wherever possible. I'm interested in improving the hard cases, not
just the average, but of course the average will improve as well.

IMO, the root of the problem with megamorphic dispatch is that it's a
bunch of chained loads. When CPU prediction works well, dispatch is
really fast. When it doesn't, dispatch is relatively slow.
(https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095211.html
is an example)

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

Sure, got that.

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