Moving the _vtable_len into Klass
mikael.gerdin at oracle.com
Wed Dec 16 11:54:13 UTC 2015
In order to reduce the number of virtual calls in the GC hot path I'd
like to propose that the field _vtable_len be moved to class Klass.
The reason for requiring access to the vtable length in the GC is that
the "nonstatic oop maps" are packed after the v and itables after the
actual C++ InstanceKlass.
In its current form, the vtable_length() accesor is a pure virtual on
Klass, and is implemented in ArrayKlass and InstanceKlass by returning a
simple member variable _vtable_len which is present in both ArrayKlass
My suggestion is to move the _vtable_len member to Klass and move the
accessor for it to Klass as well.
This also brings up the issue of InstanceKlass::vtable_length_offset(),
which is a very special beast. It returns the offset of the _vtable_len
field, in words. This means that the int field _vtable_len must be on a
word aligned address in order to work, otherwise we crash at startup in
I should note that all callers of vtable_length_offset rectify the
problem of it being a word offset by multiplying the value by wordSize
in order to convert it to a byte offset.
Does anyone know if there is a reason for vtable_length_offset to be a
If the offset of the _vtable_len field could be accessed as a byte
offset then one would not need to be so careful about the Klass field
layout when attempting to fit _vtable_len while simultaneously not
increasing the total size of the subclasses of Klass where the field is
Regardless of the vtable_length_offset mess, are there any other
concerns about making the vtable_length accessor nonvirtual?
In order to keep the code consistent and reduce duplication the vtable()
accessor could also be moved to Klass, together with start_of_vtable().
Unfortunately, there is a circular dependency with InstanceKlass for
calculating the vtable start address because the calculation depends on
the size of InstanceKlass. However I still think it might be workth
consolidating the vtable related methods in Klass since they are in fact
part of all subclasses of class.
Questions/concerns about this suggested change are of course welcome!
More information about the hotspot-dev