RFR(M) 8148481: Devirtualize Klass::vtable

[Coleen Phillimore]

Mikael,
This looks good also.

http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0/src/share/vm/oops/instanceKlass.cpp.udiff.html

Why didn't you move print_vtable to klass.cpp too rather than casting to 
intptr_t?  That looks odd.

Thanks,
Coleen

On 1/28/16 11:13 AM, Mikael Gerdin wrote:
> Hi all,
>
> Due to my recent changes in this area, Klass is now responsible for 
> maintaining the offsets and length of the embedded vtable and 
> therefore it makes sense to move all code related to the Java vtables 
> to Klass.
>
> This also allows us to remove a few unsafe casts where an ArrayKlass 
> was cast to an InstanceKlass just to get at the methods_at_vtable().
> These casts were removed from reflection.cpp, jni.cpp, 
> jvmciCompilerToVM.cpp and linkResolver.cpp, in cpCache.cpp there was 
> an alternate approach to the same problem which I've rewritten to use 
> the new way of accessing the vtable directly through Klass.
>
> Some notes:
> * I took the liberty of changing the return type of start_of_vtable() 
> to vtableEntry* since that is in fact what it is.
> * method_at_vtable is no longer inline, but I don't think that should 
> be a performance problem since it's usually only being called from 
> link resolving, cpCache or JNI calls, all of which are not 
> particularly hot paths.
>
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8148481
> Webrev: http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0
>
> Testing: JPRT + RBT on Oracle platforms.
>
> /Mikael