RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets

[Mikael Gerdin]

Hi all,

As per the previous discussion in mid-December[0] about moving the 
_vtable_length field to class Klass, here's the first RFR and webrev, 
according to my suggested plan[1]:

> My current plan is to first modify the vtable_length_offset accessor to
> return a byte offset (which is what it's translated to by all callers).
>
> Then I'll tackle moving the _vtable_len field to Klass.
>
> Finally I'll try to consolidate the vtable related methods to Klass,
> where they belong.

This change actually consists of three changes:
* modifying InstanceKlass::vtable_length_offset to become a byte offset 
and use the ByteSize type to communicate the scaling.
* modifying InstanceKlass::vtable_start_offset to become a byte offset 
and use the ByteSize type, for symmetry reasons mainly.
* adding a vtableEntry::size_in_bytes() since in many places the vtable 
entry size is used in combination with the vtable start to compute a 
byte offset for vtable lookups.

I don't foresee any issues with the fact that the byte offset is 
represented as an int, for two reasons:
1) If the offset of any of these grows to over 2 gigabytes then we have 
a huge footprint problem with InstanceKlass
2) The offsets are converted to byte offsets and stored in ints already 
in the cpu specific code I've modified.

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

Testing: JPRT on Oracle supported platforms, testing on AARCH64 and 
PPC64 would be much appreciated, appropriate mailing lists have been 
CC:ed to notify them of the request.


[0] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html
[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html

Thanks!
/Mikael