RFR(M) 8148481: Devirtualize Klass::vtable

[John Rose]

Thanks, Mikael.  These are good cleanups in a vexed area of the code.

We need them 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.

On Feb 1, 2016, at 7:44 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> Bug link: https://bugs.openjdk.java.net/browse/JDK-8148481 <https://bugs.openjdk.java.net/browse/JDK-8148481>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0 <http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0>