On Mon, 5 May 2025 18:36:43 GMT, Radim Vansa <rva...@openjdk.org> wrote:
> If methods are already sorted alphabetically, it would make sense for fields, > too. Yeah, you'd want to use the same mechanism. So each InstanceKlass will have an additional 64 bit pointer, and this mapping array if JVMTI is on. For methods, there's a capability that you can test `can_maintain_original_method_order` but I don't see the same capability for fields. I assume it's because fields have never previously been reordered (?) from declaration order. Maybe the compression is still a win in footprint size with this extra pointer and mapping array. It would be a savings with your class with your huge number of fields. The other reason to compress the field stream was to avoid null bytes for fields where the attributes didn't apply (init, generic signature, etc). Compressing the fields into unsigned5 and decoding them into streams was quite a complicated change but manageable because the interface to decode them is all one has write the FieldStream iterator. This is hard to review. I'm wondering how much of a problem this is in real code, other than the case with 21k fields and if there's a way to programmatically work around this case, like decompress the fields into a hashtable or something (?) It would be interesting to see some histograms of some corpus Java code (maybe put this info in the associated bug). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2859962231
