As suggested by John Rose on 2/3/16:
We need [these cleanups] partly because we will be doing more tricks with v-tables in the future, with value types, specializations, and new arrays.
In the next round of cleanups in the same area, I'd like to see us consider moving the i-table mechanism into Klass also, since all the new types (notably enhanced arrays) will use i-tables as much as they use v-tables.
The first detail I looked for in this series of changes was the usage of Universe::base_vtable_size, which is a hack that communicates the v-table layout for Object methods to array types, and I'm not surprised to find that it is still surrounded by its own little cloud of darkness, one corner of which Kim pointed out.
We will wish to get rid of Universe::base_vtable_size when we put more methods on arrays. Or we will have to allow i-tables to be indirectly accessed and shared, a more flexible and compact option IMO.
— John
P.S. We have a practice to consider footprint costs, even tiny ones in the single bytes, with proposals such as moving these fields around. My take on that is, never let footprint stop a clean refactoring. There is a huge amount of slack in our metadata; if we need to throw a pinch of footprint dust over our shoulders to satisfy the powers that be, we should squeeze unrelated fields smaller to make a net reduction in footprint.
How to find such fields? Just do a hex dump and look for (say) consecutive runs of five or more zeroes. Except for hot path data like v-tables and super-type displays, those are opportunities for introducing var-ints (see CompressedStream and read_int_mb), or optional full-sized fields enabled by a flag bit or escape code. The complexity of such a move is localized to one class, and so is more bearable than keeping the multi-class complexity associated with a blocked refactoring.
We need [these cleanups] partly because we will be doing more tricks with v-tables in the future, with value types, specializations, and new arrays.
In the next round of cleanups in the same area, I'd like to see us consider moving the i-table mechanism into Klass also, since all the new types (notably enhanced arrays) will use i-tables as much as they use v-tables.
The first detail I looked for in this series of changes was the usage of Universe::base_vtable_size, which is a hack that communicates the v-table layout for Object methods to array types, and I'm not surprised to find that it is still surrounded by its own little cloud of darkness, one corner of which Kim pointed out.
We will wish to get rid of Universe::base_vtable_size when we put more methods on arrays. Or we will have to allow i-tables to be indirectly accessed and shared, a more flexible and compact option IMO.
— John
P.S. We have a practice to consider footprint costs, even tiny ones in the single bytes, with proposals such as moving these fields around. My take on that is, never let footprint stop a clean refactoring. There is a huge amount of slack in our metadata; if we need to throw a pinch of footprint dust over our shoulders to satisfy the powers that be, we should squeeze unrelated fields smaller to make a net reduction in footprint.
How to find such fields? Just do a hex dump and look for (say) consecutive runs of five or more zeroes. Except for hot path data like v-tables and super-type displays, those are opportunities for introducing var-ints (see CompressedStream and read_int_mb), or optional full-sized fields enabled by a flag bit or escape code. The complexity of such a move is localized to one class, and so is more bearable than keeping the multi-class complexity associated with a blocked refactoring.
- relates to
-
JDK-8011610 NPG: Class metaspace limits number of classes for UseCompressedKlassPointers
-
- Closed
-