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