RFR(M) 8148481: Devirtualize Klass::vtable

[Coleen Phillimore]

Hi John,

I'm going to file an RFE for 10 with this idea.  Cleanups like this that 
help with value types and the future directions of Java are worth doing 
before we start working on value types and the future directions of java.

I've been looking through metaspace at all the zeroes recently.  One 
cause is that Arrays have to have the same vtable offset as 
InstanceKlass.  Arrays are thus 70 words long with 66 (ish) of them all 
zero.   I would really like to see vtables and itables be pointed to by 
Klass.  That way they can be expanded during class redefinition (think 
adding methods) without having to replace the InstanceKlass, which turns 
out to be not practical wrt performance. Also itables/vtables could be 
shared by different classes if that's part of the new directions.  
Having a fixed size InstanceKlass would also improve the compaction of 
the class metaspace, which is still fixed size and doesn't grow.

Still not sure what places we have no performance considerations in 
order to use CompressedStream.  But yes, we have too many zeros in 
metaspace.

Thank you for the ideas!
Coleen

On 2/3/16 4:33 PM, John Rose wrote:
> 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 
> <mailto:mikael.gerdin at oracle.com>> wrote:
>
>> Bug link:https://bugs.openjdk.java.net/browse/JDK-8148481
>> Webrev:http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0 
>> <http://cr.openjdk.java.net/%7Emgerdin/8148481/webrev.0>
>