- Virtual method table
A virtual method table, virtual function table,
dispatch table , or vtable, is a mechanism used inprogramming language to support dynamic dispatch (or run-time method binding).Suppose a program contains several classes in an inheritance hierarchy: a superclass,
Cat
, and two subclasses,HouseCat
andLion
. ClassCat
defines avirtual function namedspeak
, so its subclasses may provide an appropriate implementation (i.e., either meow or roar).When the program calls the
speak
method on aCat
pointer (which can point to aCat
class, or any subclass ofCat
), the run-time environment must be able to determine which implementation to call, depending on the actual type of object that is pointed to.There are a variety of different ways to implement such dynamic dispatch, but the vtable solution is especially common among
C++ and related languages (such as D and C#). Languages which separate the programmatic interface of objects from the implementation, likeVisual Basic and Delphi, also tend to use the vtable approach, because it allows objects to use a different implementation simply by using a different set of method pointers.Implementation
An object's dispatch table will contain the addresses of the object's dynamically bound methods. Method calls are performed by fetching the method's address from the object's dispatch table. The dispatch table is the same for all objects belonging to the same class, and is therefore typically shared between them. Objects belonging to type-compatible classes (for example siblings in an inheritance hierarchy) will have dispatch tables with the same layout: the address of a given method will appear at the same offset for all type-compatible classes. Thus, fetching the method's address from a given dispatch table offset will get the method corresponding to the object's actual class. [Ellis & Stroustrup 1990, pp. 227–232]
The C++ standards do not mandate exactly how dynamic dispatch must be implemented, but compilers generally use minor variations on the same basic model.
Typically, the compiler creates a separate vtable for each class. When an object is created, a pointer to this vtable, called the virtual table pointer or vpointer, is added as a hidden member of this object (often the first member). The compiler also generates "hidden" code in the constructor of each class to initialize the vpointers of its objects to the address of the corresponding vtable.
Example
Consider the following class declarations in
C++ syntax :used to derive the following class:
and the following piece of C++ code:
G++ 3.4.6 from GCC produces the following 32 bit memory layout for the object
b2
:G++'s-fdump-class-hierarchy
argument can be used to dump virtual method tables for manual inspection. For AIX VisualAge XlC compiler, use-qdump_class_hierarchy
to dump class hierarchy and virtual function table layout.]b2: +0: pointer to virtual method table of B2 +4: value of int_in_b2virtual method table of B2: +0: B2::f2() +4: B2::~B2()
and the following memory layout for the object
d
:d: +0: pointer to virtual method table of D (for B1) +4: value of int_in_b1 +8: pointer to virtual method table of D (for B2) +16: value of int_in_b2 +20: value of int_in_dvirtual method table of D (for B1): +0: B1::f1() +4: D::~D() +8: D::d() +12: D::f2()
virtual method table of D (for B2): +0: D::f2() // B2::f2() is overridden by D::f2() +4: D::~D()
Note that non-virtual functions (such as
f0
) do not generally appear in the vtable, but there are exceptions in some special cases (such as the default constructor).Overriding of the method
f2()
in classD
is implemented by duplicating the virtual method table ofB2
and replacing the pointer toB2::f2()
with a pointer toD::f2()
.Multiple inheritance and thunks
The G++ compiler implements the
multiple inheritance of the classesB1
andB2
in classD
using two virtual method tables, one for each base class. (There are other ways to implement multiple inheritance, but this is the most common.) This leads to the necessity for "pointer fixups " (thunk s) when casting.Consider the following C++ code:While
d
andb1
will point to the same memory location after execution of this code,b2
will point to the locationd+8
(eight bytes beyond the memory location ofd
). Thus,b2
points to the region withind
which "looks like" an instance ofB2
, i.e., has the same memory layout as an instance ofB2
.Invocation
A call to
d->f1()
is handled by dereferencingd
'sD::B1
vpointer, looking up thef1
entry in the vtable, and then dereferencing that pointer to call the code.In the case of single inheritance (or in a language with only single inheritance), if the vpointer is always the first element in
d
(as it is with many compilers), this reduces to the following pseudo-C++:In the more general case, as above, calling
f1()
,D::f2()
, andB2::f2()
ond
are more complicated:By comparison, a call to
d->f0()
is much simpler:Efficiency
A virtual call requires at least an extra indexed dereference, and sometimes a "fixup" addition, compared to a non-virtual call, which is simply a jump to a compiled-in pointer. Therefore, calling virtual functions is inherently slower than calling non-virtual functions. Experiments indicate that approximately 6-13% of execution time is spent simply dispatching to the correct function, though the overhead can be as high as 50% [Driesen, Karel and Hölzle, Urs, [http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf "The Direct Cost of Virtual Function Calls in C++"] , OOPSLA 1996] .
Furthermore, in environments where JIT compilation is not in use, virtual function calls usually cannot be inlined. While a compiler could replace the lookup and indirect call with, for instance, a conditional execution of each inlined body, such optimizations are not common.
To avoid this overhead, compilers usually avoid using vtables whenever the call can be resolved at compile time.
Thus, the call to
f1
above may not require a vtable lookup because the compiler may be able to tell thatd
can only hold aD
at this point, andD
does not overridef1
. Or the compiler (or optimizer) may be able to detect that there are no subclasses ofB1
anywhere in the program that overridef1
. The call toB1::f1
orB2::f2
will probably not require a vtable lookup because the implementation is specified explicitly (although it does still require the 'this'-pointer fixup).Comparison with alternatives
The vtable is generally a good performance trade-off to achieve dynamic dispatch, but there are alternatives, such as binary tree dispatch, with higher performance but different costs [Zendra, Olivier and Driesen, Karel, [http://www.sagecertification.org/events/javavm02/full_papers/zendra/zendra_html/index.html "Stress-testing Control Structures for Dynamic Dispatch in Java"] , Pp. 105–118, Proceedings of the USENIX 2nd Java Virtual Machine Research and Technology Symposium, 2002 (JVM '02)] .
However, vtables only allow for
single dispatch on the special "this" parameter, in contrast tomultiple dispatch (as inCLOS or Dylan), where the types of all parameters can be taken into account in dispatching.Vtables also only work if dispatching is constrained to a known set of methods, so they can be placed in a simple array built at compile time, in contrast to
duck typing languages (such asSmalltalk , Python orJavaScript ).Languages that provide either or both of these features often dispatch by looking up a string in a hash table, or some other equivalent method. There are a variety of tricks to speed this up (e.g., interning/tokenizing method names, caching lookups,
just-in-time compilation ), and dispatch time often does not have a significant effect on total processing time, but nonetheless, vtable lookup is obviously faster. Vtables are also simpler to implement and debug, and closer to the "C spirit" than hash tables of strings.See also
*
Virtual inheritance Notes
References
* Margaret A. Ellis and
Bjarne Stroustrup (1990) The Annotated C++ Reference Manual. Reading, MA: Addison-Wesley. (ISBN 0-201-51459-1)
Wikimedia Foundation. 2010.