RFR(M) 8148481: Devirtualize Klass::vtable

Mikael Gerdin mikael.gerdin at oracle.com
Thu Jan 28 16:13:25 UTC 2016


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


More information about the hotspot-dev mailing list