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

[Mikael Gerdin]

Hi Edward,

On 2016-01-19 11:07, Edward Nevill wrote:
> Hi Mikael,
>
> I tried a release and fastdebug build on aarch64. The release build builds fine and passes a basic smoke test but the fastdebug build fails with the following errors.
>
> /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp: In static member function 'static void CompilerToVM::Data::initialize()':
> /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:153:37: error: cannot convert 'ByteSize' to 'int' in assignment
>     InstanceKlass_vtable_start_offset = InstanceKlass::vtable_start_offset();
>                                       ^
> /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:154:38: error: cannot convert 'ByteSize' to 'int' in assignment
>     InstanceKlass_vtable_length_offset = InstanceKlass::vtable_length_offset() * HeapWordSize;
>                                        ^
> After fixing these the fastdebug build completed and passed the same basic tests.

Thanks for testing!
As to the compilation failures this is probably due to me creating the 
patch before hs-comp was merged into hs-rt.
I'll rebase it and fix the jvmci issue.

/Mikael

>
> All the best,
> Ed.
>
> On Fri, 2016-01-15 at 18:04 +0100, Mikael Gerdin wrote:
>> 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
>
>