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

[Andrew Haley]

On Wed, 9 Oct 2024 06:07:13 GMT, John R Rose <jrose at openjdk.org> wrote:

> If the interfaces had a compact numbering, and there were a side table mapping the compact numbers to interface Klass* pointers, then I think Andrew's code would still work (with natural adjustments).

Probably, yes. I can pack klass ID+ [iv]table offset into a word to identify a method, or use a compressed metadata pointer. But I have a data dependency on a table load to get from a compressed Klass ID of some sort to a `Klass*`, that's a 3-to-5-cycle stall.

> But managing such a side table is at least as complicated as just doing the pointer compression stuff we do. (Hence my comment that we haven't had to invent side tables yet.)
> 
> Because of CDS I don't think we can treat concretes and abstracts (or even just classes and interfaces) as disjoint metadata types with separate independent compression tactics or representations. I think we need a subtype/supertype relation between the "narrowest" and merely "narrower" klass IDs.

I think that's right.

Notwithstanding any side tables etc., it would be nice to make sure that all metadata is reachable with a 4Gbyte offset from some base. It's not so hard to make sure that concrete and abstract `Klass*` (and all `Method*`s) can be in that range, simply(?) by allocating everything contiguously.

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

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