JVM Method Dispatch: Vtables & Itables

Static vs. Dynamic Dispatch: A Tale of Two Bindings

When you call a method in Java, the JVM must determine exactly which block of code to execute. This decision-making process, called method dispatch (or method binding), can happen at two different times: compile time or runtime.

Static Dispatch (Early Binding)
This occurs when the compiler can determine the exact method to be called without any ambiguity. Since the decision is made early (at compile time), it's called early binding. This is the case for methods that cannot be overridden:

• private methods: They are only visible within their own class, so there's no possibility of a subclass overriding them.
• static methods: They belong to the class, not an object instance, so their implementation is fixed.
• final methods: The final keyword explicitly prevents overriding.
• Constructors: These are implicitly private and are called with a special bytecode instruction, invokespecial.

In all these cases, the compiler knows the exact memory address of the code to execute and can hardcode it into the bytecode.

Dynamic Method Dispatch (Late Binding)
This is the mechanism that enables polymorphism. It occurs when the method to be called depends on the actual runtime type of the object, not the compile-time type of the reference variable. The decision is deferred until runtime, hence "late binding."

Let's see this in action. The following video provides a clear, code-driven example of runtime polymorphism.

As the video demonstrates, when you have A obj = new B();, a call to obj.show() executes the show() method from class B, even though the reference obj is of type A. The compiler only knows that obj has a show() method, but the JVM, at runtime, inspects the actual object (new B()) and dispatches the call to its specific implementation.

But how does the JVM perform this "inspection" so efficiently?

The Vtable: A Class's Method Directory

The secret lies in the virtual table, or vtable. In the last lesson, you learned that every object has a klass pointer in its header. This pointer directs the JVM to a C++ structure in Metaspace called InstanceKlass, which represents the object's class. As you'll see in the resources, this InstanceKlass contains the vtable.

A vtable is an array of pointers to method implementations. For a given class hierarchy:

• The base class (Animal) has a vtable with entries for all its virtual methods (in Java, all non-private, non-static, non-final methods are virtual by default).
• When a subclass (Dog) extends the base class, it gets a copy of the parent's vtable.
• If the subclass overrides a method (e.g., speak()), the corresponding pointer in its vtable is updated to point to the Dog.speak() implementation.
• If it doesn't override a method (e.g., eat()), that vtable entry continues to point to the Animal.eat() implementation.

A virtual method call, which uses the invokevirtual bytecode instruction, is resolved as a three-step process:

1. Get the object's klass pointer from its header.
2. From the InstanceKlass, find the vtable.
3. Look up the method pointer at a pre-determined, fixed offset in the vtable and jump to that code address.

This concept of vtables is not unique to Java. Given your background in C, the following explanation, which approaches the topic from an assembly and C++ perspective, will provide a solid, low-level intuition.

The Interface Challenge: Why Vtables Aren't Enough

The vtable model works beautifully for single class inheritance because there is a clear, linear hierarchy. But what about interfaces? A class can implement multiple interfaces, each with its own set of methods.

Consider this scenario:

class Car implements Drivable, Maintainable { ... }

Drivable d = new Car();
d.turn("left"); // Method from Drivable

Maintainable m = new Car();
m.changeOil(); // Method from Maintainable

The Drivable interface might define turn() as its first method, so its vtable slot would be at index 0. The Maintainable interface might define changeOil() as its first method, also at index 0. A single vtable in the Car class cannot satisfy both layouts simultaneously.

To solve this, the JVM uses a different mechanism for interface method calls (invokeinterface): interface tables, or itables.

An InstanceKlass for a class contains a separate itable for each interface it implements. An itable is a data structure that links an interface to a method table specific to that interface's layout. When an interface method is called, the JVM performs a more complex lookup:

1. Follow the object's klass pointer to its InstanceKlass.
2. Search through the list of itables in the InstanceKlass.
3. For each itable, check if it corresponds to the target interface.
4. Once the correct itable is found, use the method's fixed offset within that table to find the method address and execute it.

This process, especially the linear search through itables, sounds much slower than a direct vtable lookup. And it is. But the JVM has a powerful trick up its sleeve.

Making Dynamic Dispatch Fast: Inline Caching

In practice, dynamic dispatch is often just as fast as static dispatch. This is thanks to aggressive optimization by the Just-In-Time (JIT) compiler, primarily through a technique called inline caching.

The JIT observes code as it runs. At a virtual or interface call site (e.g., animal.speak()), it notices that the object is usually of the same type (e.g., Dog).

• Monomorphic Call Site: If a call site has only ever seen one type of object (Dog), the JIT can perform a radical optimization. It replaces the expensive vtable/itable lookup with a simple check: if (animal.getClass() == Dog.class). If this check passes, it makes a direct, hardcoded call to Dog.speak(), effectively bypassing dynamic dispatch entirely. This is the "fast path."
• Polymorphic/Megamorphic Call Site: If the call site sees a few different types (bimorphic) or many types (megamorphic), the JIT may use slightly more complex checks or eventually give up and revert to the full, slower vtable/itable lookup.

This adaptive optimization is why performance-critical code in Java can heavily leverage polymorphism without a significant penalty.

Conclusion

Today, we've connected the dots from the high-level concept of polymorphism to the low-level JVM machinery that makes it work. You now have a robust mental model of how your method calls are executed "under the hood."

Key Takeaways:

• Static Dispatch is for methods whose implementation is known at compile time (private, static, final), making it fast and simple.
• Dynamic Dispatch is for virtual methods, where the implementation is chosen at runtime based on the object's actual type, enabling polymorphism.
• The JVM uses vtables for virtual method calls within a class hierarchy. This is a direct, offset-based lookup that is very efficient.
• For interface methods, the JVM uses itables, which involves a slower search but correctly handles multiple interface inheritance.
• The klass pointer in an object's header is the starting point for both vtable and itable lookups.
• Inline Caching by the JIT compiler is a critical optimization that makes dynamic dispatch extremely fast in most real-world scenarios by creating "fast paths" for frequently seen types at call sites.

In our next module, we will shift our focus from how objects behave to how they are managed and eventually reclaimed. Now that you understand an object's life and function, we will explore its death and recycling in our first lesson on Garbage Collection fundamentals.