On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >> have no instances created for them don't require compressed class pointers. >> The generated LambdaForm classes are also AllStatic, and changing them to >> abstract moves them to non-class metaspace too. It's not technically great >> to make them abstract and not final but you can't have both. Java classfile >> access flags have no way of specifying something like AllStatic. >> >> Tested with tier1-8. > > 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 ------------- PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401747594
