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 8 Oct 2024, at 4:07, Andrew Haley wrote: > On 9/10/24 12:42, Coleen Phillimore wrote: >> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested >> changes. > > I'm a bit concerned about this one. > > I'm working on megamorphic dispatch, and a uniform representation of > compressed class pointers allows me to squeeze klass+offset into a > single 64-bit word. This in turn allows fast and simple method > lookups. I need, at least, to be able to use compressed interface > pointers. If interfaces are "somewhere else", and thus incompressible, > I can't do what I need to do. This is an interesting use of compressed klass pointers. It looks like the compression needs to be partial, down to about 32 bits. A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout. 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. (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.) > … If, however, klass and non-klass > metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much > rather use compressed klass pointers without having to decode them. 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.) > All I need is a way to represent interface pointers in a compact way > in lookup tables, and to be able to get from compressed class pointers > to the address. As long as interface pointers are in a 32-bit range > and there's a fast way to get from compressed class to address that's > OK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401375521
