On Wed, 9 Oct 2024 09:00:06 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 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 > @theRealAph I do not know your idea regarding this matter but does > compressing interface pointers independently from concrete class pointers > help? Of course that is possible, but it add complexity; and my goal is reducing complexity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402696292
