On Wed, 9 Oct 2024 05:53:51 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> 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. @theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401380082
