RFR(M) 8148481: Devirtualize Klass::vtable
chris.plummer at oracle.com
Fri Jan 29 18:52:54 UTC 2016
On 1/28/16 8: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.
More information about the hotspot-dev