Compile Time Vs Runtime Polymorphism - Learning Module

Loading content...

0/246

How the Compiler/Runtime Resolves Calls

The Journey from Name to Machine Code

When you write object.method(), a remarkable journey begins. The name "method" must be translated into an actual memory address—the location of executable code. This translation can happen at different times: during compilation (static binding), during program loading (link-time binding), or during execution (dynamic binding).

Understanding how this resolution happens reveals why some code can be optimized aggressively while other code pays runtime costs for flexibility. It explains mysterious errors, unexpected behavior, and the performance characteristics of object-oriented systems.

This page traces the complete path from source code to executed call, covering the compilation phases for static resolution and the runtime mechanisms for dynamic dispatch.

What You Will Learn

By the end of this page, you will understand: how compilers resolve overloaded method calls, how virtual method tables enable runtime dispatch, the role of static vs dynamic type in binding decisions, and how JIT compilers optimize virtual calls. You'll see the complete picture of method resolution.

The Binding Spectrum: Early to Late

Binding is the process of associating a name (method name, function name) with the code that should execute. Different bindings occur at different points in the program's lifecycle:

1. Compile-Time Binding (Static/Early Binding)

The compiler determines exactly which function will be called. The call instruction in the generated code contains the actual address (or a placeholder that the linker fills in). No runtime decisions are needed.

Method overloading
Non-virtual method calls
static, final, or private methods
Template/generic instantiation

2. Link-Time Binding

The linker resolves references between separately compiled modules. Function addresses are fixed when the executable is created or when libraries are loaded.

Cross-module function calls
Library function linkage
Dynamic library loading (still before execution)

3. Runtime Binding (Dynamic/Late Binding)

The actual function is determined during execution, based on information available only at that moment (typically the object's actual type).

Virtual method calls
Interface method dispatch
Reflection-based invocation

Converting Mermaid diagram...

Binding Time Comparison
Binding Time	Information Used	Performance	Flexibility
Compile-time	Static types, signatures	Best (inlining possible)	None (fixed at compile)
Link-time	Symbol resolution	Excellent (direct calls)	Minimal (library swapping)
Runtime	Actual object type	Overhead (indirection)	Maximum (true polymorphism)

The Trade-off Principle

Earlier binding means more optimization opportunities but less flexibility. Later binding means more flexibility but runtime costs. The art of system design is choosing the right binding time for each interaction: static where performance matters and types are known, dynamic where flexibility and extensibility are essential.

Compile-Time Resolution: The Overload Selection Process

When the compiler encounters a method call, it performs a sophisticated resolution process to determine which method implementation to bind. This process uses only static information—the declared types of variables, not the actual objects that might exist at runtime.

The complete overload resolution algorithm:

Overload Resolution Steps

•Name lookup — Find all methods with the given name that are visible/accessible at the call site. This includes inherited methods and methods brought in via imports/using statements.
•Candidate set formation — From the name lookup results, identify all methods that could potentially accept the arguments (considering conversions).
•Argument matching — For each candidate, determine if the actual arguments can be converted to the formal parameters. Record the conversion sequence required.
•Viable candidates filtering — Eliminate candidates that cannot accept the arguments even with conversions. Methods with wrong arity are eliminated.
•Ranking conversions — Among viable candidates, rank them by the "cost" of conversions required. Exact matches beat widening, widening beats boxing, boxing beats varargs.
•Best match selection — Select the candidate requiring the least costly conversions. If there's a unique best match, resolution succeeds.
•Ambiguity detection — If multiple candidates are equally good, report an ambiguity error. If no candidates are viable, report no matching method error.

OverloadResolutionExamples
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
public class OverloadResolution {
    
    // Overload set for demonstration
    void process(int x) { 
        System.out.println("int: " + x); 
    }
    void process(long x) { 
        System.out.println("long: " + x); 
    }
    void process(double x) { 
        System.out.println("double: " + x); 
    }
    void process(Integer x) { 
        System.out.println("Integer: " + x); 
    }
    void process(Number x) { 
        System.out.println("Number: " + x); 
    }
    void process(Object x) { 
        System.out.println("Object: " + x); 
    }
    void process(int... x) { 
        System.out.println("varargs: " + Arrays.toString(x)); 
    }
    
    public static void main(String[] args) {
        OverloadResolution demo = new OverloadResolution();
        
        // Resolution trace for each call:
        
        demo.process(42);
        // Candidates: all 7 methods (42 can convert to each)
        // Best: process(int) - exact match
        // Output: "int: 42"
        
        demo.process(42L);
        // Candidates: long, double, Integer(no), Number, Object, varargs
        // Best: process(long) - exact match for long literal
        // Output: "long: 42"
        
        demo.process((short) 42);
        // Candidates: int, long, double, Integer(no), Number, Object, varargs
        // Best: process(int) - short widens to int, closest primitive
        // Output: "int: 42"
        
        demo.process(Integer.valueOf(42));
        // Candidates: int, long, double, Integer, Number, Object, varargs
        // Best: process(Integer) - exact match for Integer object
        // Output: "Integer: 42"
        
        demo.process(3.14f);
        // Candidates: double, Number, Object
        // Best: process(double) - float widens to double
        // Output: "double: 3.14"
        
        demo.process("hello");
        // Candidates: Object only (String is not Number or primitive)
        // Best: process(Object) - only viable option
        // Output: "Object: hello"
        
        demo.process(1, 2, 3);
        // Candidates: varargs only (3 arguments)
        // Best: process(int...) - only viable for 3 args
        // Output: "varargs: [1, 2, 3]"
        
        // Ambiguity example (if we had both):
        // void process(int x, double y) { }
        // void process(double x, int y) { }
        // demo.process(1, 2);  // AMBIGUOUS! Both equally good.
    }
}

The conversion ranking hierarchy (Java):

Priority	Conversion Category	Examples	Notes
1	Identity (exact match)	`int` → `int`	Perfect match, always preferred
2	Widening primitive	`byte` → `short` → `int` → `long` → `float` → `double`	No information loss
3	Widening reference	`String` → `Object`, `ArrayList` → `List`	Subtype to supertype
4	Boxing	`int` → `Integer`, `boolean` → `Boolean`	Primitive to wrapper
5	Unboxing	`Integer` → `int`	Wrapper to primitive
6	Widening + unboxing	`Byte` → `int` (unbox then widen)	Combined conversion
7	Varargs	`int, int, int` → `int...`	Last resort

Static Types Only

Crucially, overload resolution uses only the declared types of expressions. If you write Object obj = "hello"; process(obj);, the compiler sees Object, not String. It selects process(Object) even though the actual runtime object is a String. Static polymorphism cannot see runtime types.

Runtime Resolution: Virtual Method Dispatch

When a method call requires runtime binding (virtual methods, interface methods), the compiler cannot emit a direct call instruction. Instead, it emits code that performs a runtime lookup based on the actual object type.

The two-step compiled code for virtual calls:

Fetch the vtable pointer — Every object with virtual methods contains a hidden pointer (vptr) to its class's vtable. The compiled code loads this pointer from the object.
Index into the vtable — Each virtual method has a fixed index in the vtable. The call fetches the function pointer at that index and calls through it.

This is remarkably efficient—just two memory loads and an indirect call—but it's still more expensive than a direct call and prevents inlining.

VirtualDispatchMechanism
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Source code
class Shape {
public:
    virtual void draw() = 0;      // vtable index 0
    virtual double area() = 0;    // vtable index 1
    virtual ~Shape() {}           // vtable index 2
};
 
class Circle : public Shape {
    double radius;
public:
    Circle(double r) : radius(r) {}
    void draw() override { /*...*/ }       // Overrides at index 0
    double area() override { return 3.14159 * radius * radius; }  // Index 1
};
 
void render(Shape* shape) {
    shape->draw();  // Virtual call
}
 
// What the compiler generates (conceptual):
//
// Circle object layout:
// +------------------------+
// | vptr (8 bytes)         | ---> Points to Circle_vtable
// | radius (8 bytes)       |
// +------------------------+
//
// Circle_vtable layout:
// +------------------------+
// | [0]: Circle::draw      |
// | [1]: Circle::area      |
// | [2]: Circle::~Circle   |
// +------------------------+
//
// Compiled 'render' function (x86-64 assembly, simplified):
//
// render(Shape* shape):
//     mov  rax, [rdi]        ; Load vptr from object (rdi = this pointer)
//     call [rax]             ; Call function at vtable[0] (draw is index 0)
//     ret
//
// The key insight: the address called is determined by the OBJECT's vptr,
// which points to the vtable of the object's ACTUAL class (Circle, not Shape).
 
// Interface dispatch in Java (similar concept, different mechanism):
// Java uses an "itable" (interface table) or method handle dispatch
// for interface calls, which is slightly more expensive than class vtables.

Interface method dispatch:

Interface methods add complexity because a class can implement multiple interfaces, and the same interface method might appear at different vtable indices in different implementing classes.

Solutions used by different runtimes:

Platform	Interface Dispatch Strategy	Performance
C++	No native interfaces; use abstract classes with vtables	Same as virtual
Java HotSpot	Interface method tables (itables) + inline caching	Slightly slower than class vtables
.NET CLR	Interface dispatch slots with hashmap fallback	Comparable to Java
Objective-C/Swift	Selector-based message dispatch	More flexible, more overhead

Inline Caching Optimization

JIT compilers use inline caching to speed up virtual calls. At each call site, the runtime caches the last type seen and its method address. If the same type appears again (common in practice), it can skip the vtable lookup and call directly. Monomorphic sites (always the same type) become as fast as direct calls. Polymorphic sites (multiple types) use polymorphic inline caches (PICs).

Static Type vs Dynamic Type: The Critical Distinction

The behavior of method calls depends on understanding two different notions of "type":

Static type (declared type, compile-time type):

The type declared in the variable, parameter, or expression
Known to the compiler during compilation
Used for overload resolution and compile-time type checking
Fixed throughout the variable's scope

Dynamic type (actual type, runtime type):

The actual type of the object reference points to
Known only at runtime
Used for virtual method dispatch
Can vary as references are reassigned

The interaction:

For a call variable.method(args), the compiler uses the static type to determine which method signature applies (overload resolution). If that method is virtual, the runtime uses the dynamic type to determine which implementation to call.

StaticVsDynamicType
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
class Animal {
    public void speak() {
        System.out.println("Animal sound");
    }
    
    public void speak(String message) {
        System.out.println("Animal says: " + message);
    }
}
 
class Dog extends Animal {
    @Override
    public void speak() {
        System.out.println("Woof!");
    }
    
    @Override
    public void speak(String message) {
        System.out.println("Dog barks: " + message);
    }
    
    public void fetch() {
        System.out.println("Fetching...");
    }
}
 
public class TypeDistinction {
    public static void main(String[] args) {
        // Static type: Animal, Dynamic type: Dog
        Animal animal = new Dog();
        
        // ----- Overload Resolution (uses STATIC type: Animal) -----
        // Compiler sees: Animal has speak() and speak(String)
        // For call speak("hello"), compiler selects speak(String)
        animal.speak();          // Resolved to speak() at compile time
        animal.speak("hello");   // Resolved to speak(String) at compile time
        
        // ----- Virtual Dispatch (uses DYNAMIC type: Dog) -----
        // At runtime, actual object is Dog
        // speak() -> Dog.speak() -> "Woof!"
        // speak(String) -> Dog.speak(String) -> "Dog barks: hello"
        
        // Output:
        // Woof!
        // Dog barks: hello
        
        // ----- Static type limits visibility -----
        // animal.fetch();  // COMPILE ERROR!
        // Static type is Animal, which doesn't have fetch()
        // Even though dynamic type (Dog) has fetch(), compiler doesn't know
        
        // Cast reveals methods of static type
        ((Dog) animal).fetch();  // Works: static type is now Dog
    }
    
    // Method that demonstrates overload selection with polymorphism
    public static void demonstrate(Animal a) {
        a.speak();  // Virtual call to speak()
    }
    
    public static void demonstrate(Dog d) {
        d.speak();  // Virtual call to speak()
        d.fetch();  // Also available because static type is Dog
    }
}
 
// The two-phase process summarized:
// 1. COMPILE TIME: Compiler uses STATIC type for:
//    - Determining visible methods
//    - Overload resolution
//    - Access control checks
//
// 2. RUNTIME: JVM uses DYNAMIC type for:
//    - Virtual method dispatch
//    - Finding actual implementation to execute

Static Type Determines

•Which methods are visible
•Which overload is selected
•Access control (public/private)
•Whether the call compiles at all
•Generic type constraints

Dynamic Type Determines

•Which implementation executes
•Behavior of virtual methods
•Object identity (instanceof result)
•Actual memory layout
•Destructor chain

The Source of "Method Not Found" Errors

When you get a compile error saying a method doesn't exist—even though you "know" the object has that method—you're witnessing the static type limitation. The compiler only sees the declared type. If Animal doesn't have fetch(), you can't call it through an Animal variable, period. Cast or change the declared type.

Method Hiding vs Overriding: A Critical Distinction

Two mechanisms can make a derived class method "replace" a base class method: overriding and hiding. They look similar but behave very differently.

Overriding (dynamic dispatch):

Applies to virtual/overridable methods
The derived version replaces the base version for all calls through objects of derived type
Resolution uses dynamic type

Hiding/Shadowing (static dispatch):

Applies to non-virtual methods, static methods, or fields
The derived version hides the base version in the derived class scope
Resolution uses static type—base type reference still sees base version!

HidingVsOverriding
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
class Parent {
    // Instance method - can be overridden
    public void instanceMethod() {
        System.out.println("Parent instance method");
    }
    
    // Static method - can only be hidden, not overridden
    public static void staticMethod() {
        System.out.println("Parent static method");
    }
    
    // Field - can only be hidden, not overridden
    public String name = "Parent";
}
 
class Child extends Parent {
    // OVERRIDING: Replaces parent's instance method
    @Override
    public void instanceMethod() {
        System.out.println("Child instance method");
    }
    
    // HIDING: Hides parent's static method (NOT override!)
    // Note: @Override would cause compile error here
    public static void staticMethod() {
        System.out.println("Child static method");
    }
    
    // HIDING: Hides parent's field (NOT override!)
    public String name = "Child";
}
 
public class HidingDemo {
    public static void main(String[] args) {
        Child child = new Child();
        Parent parentRef = child;  // Same object, different static types
        
        // OVERRIDING: Behavior based on DYNAMIC type (Child)
        child.instanceMethod();      // "Child instance method"
        parentRef.instanceMethod();  // "Child instance method" - SAME!
        // Both calls invoke Child.instanceMethod() because:
        // - Method is virtual (overridden)
        // - Dynamic type is Child
        
        // HIDING: Behavior based on STATIC type
        Child.staticMethod();        // "Child static method"
        Parent.staticMethod();       // "Parent static method" - DIFFERENT!
        child.staticMethod();        // "Child static method" (static type Child)
        parentRef.staticMethod();    // "Parent static method" (static type Parent)
        // The last two differ because:
        // - Static methods use static type for resolution
        // - parentRef's static type is Parent
        
        // FIELDS: Also hiding, based on STATIC type
        System.out.println(child.name);       // "Child"
        System.out.println(parentRef.name);   // "Parent" - DIFFERENT!
        // Fields are never overridden, always hidden
        
        // This asymmetry is a common source of bugs!
    }
}

The Hiding Trap

Method hiding is almost always unintended and a source of bugs. If you define a method in a derived class with the same signature as a base class non-virtual method, you've hidden it. Calls through base type references will still invoke the base version. Always use virtual (C++) or understand that Java instance methods are virtual by default. C# requires new keyword to explicitly acknowledge hiding.

JIT Compilation and Devirtualization

Modern runtime environments employ Just-In-Time (JIT) compilation to optimize code during execution. One of the most important JIT optimizations is devirtualization—converting virtual calls to direct calls when the runtime can prove which method will be called.

Why devirtualization matters:

Virtual calls prevent inlining. If the JIT can't inline small methods, performance suffers. Devirtualization enables:

Direct calls (no vtable lookup)
Method inlining (eliminates call overhead entirely)
Further optimizations after inlining (constant propagation, dead code elimination)

Devirtualization techniques:

JIT Devirtualization Strategies

•Class Hierarchy Analysis (CHA) — If a virtual method has only one implementation in the loaded class hierarchy, devirtualize it. Must invalidate if new subclass loads.
•Type profiling — Track which types actually appear at each call site. If always the same type (monomorphic), devirtualize optimistically.
•Guarded devirtualization — Emit a type check, and if it matches the expected type, use direct call; otherwise fall back to virtual dispatch.
•Inline caching — Cache the last type seen at each call site. Reuse if same type appears again.
•Final method optimization — Methods marked final cannot be overridden. Direct call is always safe.
•Escape analysis — If an object doesn't escape the current method, its exact type is known. Direct call is safe.

DevirtualizationExample
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// The JIT optimizer in action
 
interface Processor {
    int process(int value);
}
 
// Only implementation of Processor in the application
class Doubler implements Processor {
    @Override
    public int process(int value) {
        return value * 2;
    }
}
 
public class ProcessorClient {
    private final Processor processor;
    
    public ProcessorClient(Processor processor) {
        this.processor = processor;
    }
    
    public int processMany(int[] values) {
        int sum = 0;
        for (int v : values) {
            // Virtual call: processor.process(v)
            sum += processor.process(v);
        }
        return sum;
    }
}
 
// When this code runs:
// 1. JIT profiles the processMany() method
// 2. Observes that 'processor' is always Doubler
// 3. Applies guarded devirtualization:
 
// Optimized version (conceptual):
// public int processMany_optimized(int[] values) {
//     int sum = 0;
//     for (int v : values) {
//         if (processor.getClass() == Doubler.class) {  // Type guard
//             sum += v * 2;  // Inlined Doubler.process()!
//         } else {
//             sum += processor.process(v);  // Virtual fallback
//         }
//     }
//     return sum;
// }
 
// With Class Hierarchy Analysis, if Doubler is the ONLY Processor:
// public int processMany_cha(int[] values) {
//     int sum = 0;
//     for (int v : values) {
//         sum += v * 2;  // No guard needed, Doubler is the only option
//     }
//     return sum;
// }
 
// Tips to help the JIT devirtualize:
 
// 1. Use 'final' classes/methods when possible
final class FinalDoubler implements Processor {
    @Override
    public int process(int value) {
        return value * 2;
    }
}
 
// 2. Keep implementations monomorphic at call sites
// Avoid mixing types in the same collection if possible
 
// 3. Avoid unnecessary interface abstraction
// If only one implementation exists, consider concrete type

Help the JIT Help You

Use final on classes and methods that shouldn't be overridden. Don't create unnecessary abstract layers. Keep call sites monomorphic when possible (same type at each call site). These practices help the JIT devirtualize, leading to significant performance improvements in hot paths.

The Complete Method Resolution Flow

Let's trace a complete method call through the entire resolution process, from source code to executed instruction.

Converting Mermaid diagram...

Walking through both paths:

Non-Virtual Method (Static Binding):

Compiler sees call to non-virtual method
Overload resolution selects the method based on static types
Compiler emits CALL <function_address> with placeholder
Linker resolves placeholder to actual address
At runtime, CPU jumps directly to that address
Zero runtime overhead for dispatch

Virtual Method (Dynamic Binding):

Compiler sees call to virtual method
Overload resolution selects the signature based on static types
Compiler notes the vtable index for that method (e.g., index 0 for draw)
Compiler emits: load vptr, load vtable[0], call through pointer
At runtime:
- CPU fetches vptr from object (offset 0)
- CPU fetches function pointer from vtable[index]
- CPU calls through that pointer
JIT may devirtualize if type becomes known
Actual method executes

The Elegance of the Design

The vtable mechanism is beautifully simple: every object carries a pointer to its class's function table. The overhead is one pointer per object plus a table per class. Method dispatch is two memory accesses. This design, used since the 1980s, remains the foundation of object-oriented runtime systems because it's hard to beat in efficiency while preserving full polymorphism.

Summary: Understanding Call Resolution

We've traced the complete journey from method call to executed code. Here are the essential insights:

Key Takeaways

•Binding occurs at different times — Compile-time for overloading and non-virtual methods, runtime for virtual methods. Earlier binding means more optimization, later binding means more flexibility.
•Overload resolution uses static types — The compiler sees only declared types. Actual object types at runtime don't affect which overload is selected.
•Virtual dispatch uses dynamic types — At runtime, the vptr of the actual object determines which implementation runs, regardless of variable declaration.
•Static type limits what you can see — Only methods visible in the static type can be called. Dynamic type only affects which version of those methods runs.
•Hiding differs from overriding — Hiding uses static type (dangerous, often unintended). Overriding uses dynamic type (expected polymorphic behavior).
•JIT devirtualization bridges the gap — Modern runtimes convert virtual calls to direct calls when types are predictable, recovering static-dispatch performance.
•The vtable mechanism is elegant — One pointer per object, one table per class, two memory accesses per call. Simple, efficient, universal.

What's next:

The final page of this module examines performance considerations in depth. We'll explore when polymorphism costs matter, how to measure dispatch overhead, and strategies for optimizing hot polymorphic code paths.

Page Complete

You now understand the complete mechanics of method resolution—from overload resolution at compile time to vtable dispatch at runtime, and how JIT compilers optimize both. This knowledge enables you to predict behavior, debug unexpected calls, and make informed design decisions.

How the Compiler/Runtime Resolves Calls

The Journey from Name to Machine Code

This page traces the complete path from source code to executed call, covering the compilation phases for static resolution and the runtime mechanisms for dynamic dispatch.

What You Will Learn

The Binding Spectrum: Early to Late

Binding is the process of associating a name (method name, function name) with the code that should execute. Different bindings occur at different points in the program's lifecycle:

1. Compile-Time Binding (Static/Early Binding)

Method overloading
Non-virtual method calls
static, final, or private methods
Template/generic instantiation

2. Link-Time Binding

The linker resolves references between separately compiled modules. Function addresses are fixed when the executable is created or when libraries are loaded.

Cross-module function calls
Library function linkage
Dynamic library loading (still before execution)

3. Runtime Binding (Dynamic/Late Binding)

The actual function is determined during execution, based on information available only at that moment (typically the object's actual type).

Virtual method calls
Interface method dispatch
Reflection-based invocation

Converting Mermaid diagram...

Binding Time Comparison
Binding Time	Information Used	Performance	Flexibility
Compile-time	Static types, signatures	Best (inlining possible)	None (fixed at compile)
Link-time	Symbol resolution	Excellent (direct calls)	Minimal (library swapping)
Runtime	Actual object type	Overhead (indirection)	Maximum (true polymorphism)

The Trade-off Principle

Compile-Time Resolution: The Overload Selection Process

The complete overload resolution algorithm:

Overload Resolution Steps

•Name lookup — Find all methods with the given name that are visible/accessible at the call site. This includes inherited methods and methods brought in via imports/using statements.
•Candidate set formation — From the name lookup results, identify all methods that could potentially accept the arguments (considering conversions).
•Argument matching — For each candidate, determine if the actual arguments can be converted to the formal parameters. Record the conversion sequence required.
•Viable candidates filtering — Eliminate candidates that cannot accept the arguments even with conversions. Methods with wrong arity are eliminated.
•Ranking conversions — Among viable candidates, rank them by the "cost" of conversions required. Exact matches beat widening, widening beats boxing, boxing beats varargs.
•Best match selection — Select the candidate requiring the least costly conversions. If there's a unique best match, resolution succeeds.
•Ambiguity detection — If multiple candidates are equally good, report an ambiguity error. If no candidates are viable, report no matching method error.

OverloadResolutionExamples
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
public class OverloadResolution {
    
    // Overload set for demonstration
    void process(int x) { 
        System.out.println("int: " + x); 
    }
    void process(long x) { 
        System.out.println("long: " + x); 
    }
    void process(double x) { 
        System.out.println("double: " + x); 
    }
    void process(Integer x) { 
        System.out.println("Integer: " + x); 
    }
    void process(Number x) { 
        System.out.println("Number: " + x); 
    }
    void process(Object x) { 
        System.out.println("Object: " + x); 
    }
    void process(int... x) { 
        System.out.println("varargs: " + Arrays.toString(x)); 
    }
    
    public static void main(String[] args) {
        OverloadResolution demo = new OverloadResolution();
        
        // Resolution trace for each call:
        
        demo.process(42);
        // Candidates: all 7 methods (42 can convert to each)
        // Best: process(int) - exact match
        // Output: "int: 42"
        
        demo.process(42L);
        // Candidates: long, double, Integer(no), Number, Object, varargs
        // Best: process(long) - exact match for long literal
        // Output: "long: 42"
        
        demo.process((short) 42);
        // Candidates: int, long, double, Integer(no), Number, Object, varargs
        // Best: process(int) - short widens to int, closest primitive
        // Output: "int: 42"
        
        demo.process(Integer.valueOf(42));
        // Candidates: int, long, double, Integer, Number, Object, varargs
        // Best: process(Integer) - exact match for Integer object
        // Output: "Integer: 42"
        
        demo.process(3.14f);
        // Candidates: double, Number, Object
        // Best: process(double) - float widens to double
        // Output: "double: 3.14"
        
        demo.process("hello");
        // Candidates: Object only (String is not Number or primitive)
        // Best: process(Object) - only viable option
        // Output: "Object: hello"
        
        demo.process(1, 2, 3);
        // Candidates: varargs only (3 arguments)
        // Best: process(int...) - only viable for 3 args
        // Output: "varargs: [1, 2, 3]"
        
        // Ambiguity example (if we had both):
        // void process(int x, double y) { }
        // void process(double x, int y) { }
        // demo.process(1, 2);  // AMBIGUOUS! Both equally good.
    }
}

The conversion ranking hierarchy (Java):

Priority	Conversion Category	Examples	Notes
1	Identity (exact match)	`int` → `int`	Perfect match, always preferred
2	Widening primitive	`byte` → `short` → `int` → `long` → `float` → `double`	No information loss
3	Widening reference	`String` → `Object`, `ArrayList` → `List`	Subtype to supertype
4	Boxing	`int` → `Integer`, `boolean` → `Boolean`	Primitive to wrapper
5	Unboxing	`Integer` → `int`	Wrapper to primitive
6	Widening + unboxing	`Byte` → `int` (unbox then widen)	Combined conversion
7	Varargs	`int, int, int` → `int...`	Last resort

Static Types Only

Runtime Resolution: Virtual Method Dispatch

The two-step compiled code for virtual calls:

Fetch the vtable pointer — Every object with virtual methods contains a hidden pointer (vptr) to its class's vtable. The compiled code loads this pointer from the object.
Index into the vtable — Each virtual method has a fixed index in the vtable. The call fetches the function pointer at that index and calls through it.

This is remarkably efficient—just two memory loads and an indirect call—but it's still more expensive than a direct call and prevents inlining.

VirtualDispatchMechanism
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Source code
class Shape {
public:
    virtual void draw() = 0;      // vtable index 0
    virtual double area() = 0;    // vtable index 1
    virtual ~Shape() {}           // vtable index 2
};
 
class Circle : public Shape {
    double radius;
public:
    Circle(double r) : radius(r) {}
    void draw() override { /*...*/ }       // Overrides at index 0
    double area() override { return 3.14159 * radius * radius; }  // Index 1
};
 
void render(Shape* shape) {
    shape->draw();  // Virtual call
}
 
// What the compiler generates (conceptual):
//
// Circle object layout:
// +------------------------+
// | vptr (8 bytes)         | ---> Points to Circle_vtable
// | radius (8 bytes)       |
// +------------------------+
//
// Circle_vtable layout:
// +------------------------+
// | [0]: Circle::draw      |
// | [1]: Circle::area      |
// | [2]: Circle::~Circle   |
// +------------------------+
//
// Compiled 'render' function (x86-64 assembly, simplified):
//
// render(Shape* shape):
//     mov  rax, [rdi]        ; Load vptr from object (rdi = this pointer)
//     call [rax]             ; Call function at vtable[0] (draw is index 0)
//     ret
//
// The key insight: the address called is determined by the OBJECT's vptr,
// which points to the vtable of the object's ACTUAL class (Circle, not Shape).
 
// Interface dispatch in Java (similar concept, different mechanism):
// Java uses an "itable" (interface table) or method handle dispatch
// for interface calls, which is slightly more expensive than class vtables.

Interface method dispatch:

Interface methods add complexity because a class can implement multiple interfaces, and the same interface method might appear at different vtable indices in different implementing classes.

Solutions used by different runtimes:

Platform	Interface Dispatch Strategy	Performance
C++	No native interfaces; use abstract classes with vtables	Same as virtual
Java HotSpot	Interface method tables (itables) + inline caching	Slightly slower than class vtables
.NET CLR	Interface dispatch slots with hashmap fallback	Comparable to Java
Objective-C/Swift	Selector-based message dispatch	More flexible, more overhead

Inline Caching Optimization

Static Type vs Dynamic Type: The Critical Distinction

The behavior of method calls depends on understanding two different notions of "type":

Static type (declared type, compile-time type):

The type declared in the variable, parameter, or expression
Known to the compiler during compilation
Used for overload resolution and compile-time type checking
Fixed throughout the variable's scope

Dynamic type (actual type, runtime type):

The actual type of the object reference points to
Known only at runtime
Used for virtual method dispatch
Can vary as references are reassigned

The interaction:

StaticVsDynamicType
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
class Animal {
    public void speak() {
        System.out.println("Animal sound");
    }
    
    public void speak(String message) {
        System.out.println("Animal says: " + message);
    }
}
 
class Dog extends Animal {
    @Override
    public void speak() {
        System.out.println("Woof!");
    }
    
    @Override
    public void speak(String message) {
        System.out.println("Dog barks: " + message);
    }
    
    public void fetch() {
        System.out.println("Fetching...");
    }
}
 
public class TypeDistinction {
    public static void main(String[] args) {
        // Static type: Animal, Dynamic type: Dog
        Animal animal = new Dog();
        
        // ----- Overload Resolution (uses STATIC type: Animal) -----
        // Compiler sees: Animal has speak() and speak(String)
        // For call speak("hello"), compiler selects speak(String)
        animal.speak();          // Resolved to speak() at compile time
        animal.speak("hello");   // Resolved to speak(String) at compile time
        
        // ----- Virtual Dispatch (uses DYNAMIC type: Dog) -----
        // At runtime, actual object is Dog
        // speak() -> Dog.speak() -> "Woof!"
        // speak(String) -> Dog.speak(String) -> "Dog barks: hello"
        
        // Output:
        // Woof!
        // Dog barks: hello
        
        // ----- Static type limits visibility -----
        // animal.fetch();  // COMPILE ERROR!
        // Static type is Animal, which doesn't have fetch()
        // Even though dynamic type (Dog) has fetch(), compiler doesn't know
        
        // Cast reveals methods of static type
        ((Dog) animal).fetch();  // Works: static type is now Dog
    }
    
    // Method that demonstrates overload selection with polymorphism
    public static void demonstrate(Animal a) {
        a.speak();  // Virtual call to speak()
    }
    
    public static void demonstrate(Dog d) {
        d.speak();  // Virtual call to speak()
        d.fetch();  // Also available because static type is Dog
    }
}
 
// The two-phase process summarized:
// 1. COMPILE TIME: Compiler uses STATIC type for:
//    - Determining visible methods
//    - Overload resolution
//    - Access control checks
//
// 2. RUNTIME: JVM uses DYNAMIC type for:
//    - Virtual method dispatch
//    - Finding actual implementation to execute

Static Type Determines

•Which methods are visible
•Which overload is selected
•Access control (public/private)
•Whether the call compiles at all
•Generic type constraints

Dynamic Type Determines

•Which implementation executes
•Behavior of virtual methods
•Object identity (instanceof result)
•Actual memory layout
•Destructor chain

The Source of "Method Not Found" Errors

Method Hiding vs Overriding: A Critical Distinction

Two mechanisms can make a derived class method "replace" a base class method: overriding and hiding. They look similar but behave very differently.

Overriding (dynamic dispatch):

Applies to virtual/overridable methods
The derived version replaces the base version for all calls through objects of derived type
Resolution uses dynamic type

Hiding/Shadowing (static dispatch):

Applies to non-virtual methods, static methods, or fields
The derived version hides the base version in the derived class scope
Resolution uses static type—base type reference still sees base version!

HidingVsOverriding
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
class Parent {
    // Instance method - can be overridden
    public void instanceMethod() {
        System.out.println("Parent instance method");
    }
    
    // Static method - can only be hidden, not overridden
    public static void staticMethod() {
        System.out.println("Parent static method");
    }
    
    // Field - can only be hidden, not overridden
    public String name = "Parent";
}
 
class Child extends Parent {
    // OVERRIDING: Replaces parent's instance method
    @Override
    public void instanceMethod() {
        System.out.println("Child instance method");
    }
    
    // HIDING: Hides parent's static method (NOT override!)
    // Note: @Override would cause compile error here
    public static void staticMethod() {
        System.out.println("Child static method");
    }
    
    // HIDING: Hides parent's field (NOT override!)
    public String name = "Child";
}
 
public class HidingDemo {
    public static void main(String[] args) {
        Child child = new Child();
        Parent parentRef = child;  // Same object, different static types
        
        // OVERRIDING: Behavior based on DYNAMIC type (Child)
        child.instanceMethod();      // "Child instance method"
        parentRef.instanceMethod();  // "Child instance method" - SAME!
        // Both calls invoke Child.instanceMethod() because:
        // - Method is virtual (overridden)
        // - Dynamic type is Child
        
        // HIDING: Behavior based on STATIC type
        Child.staticMethod();        // "Child static method"
        Parent.staticMethod();       // "Parent static method" - DIFFERENT!
        child.staticMethod();        // "Child static method" (static type Child)
        parentRef.staticMethod();    // "Parent static method" (static type Parent)
        // The last two differ because:
        // - Static methods use static type for resolution
        // - parentRef's static type is Parent
        
        // FIELDS: Also hiding, based on STATIC type
        System.out.println(child.name);       // "Child"
        System.out.println(parentRef.name);   // "Parent" - DIFFERENT!
        // Fields are never overridden, always hidden
        
        // This asymmetry is a common source of bugs!
    }
}

The Hiding Trap

JIT Compilation and Devirtualization

Why devirtualization matters:

Virtual calls prevent inlining. If the JIT can't inline small methods, performance suffers. Devirtualization enables:

Direct calls (no vtable lookup)
Method inlining (eliminates call overhead entirely)
Further optimizations after inlining (constant propagation, dead code elimination)

Devirtualization techniques:

JIT Devirtualization Strategies

•Class Hierarchy Analysis (CHA) — If a virtual method has only one implementation in the loaded class hierarchy, devirtualize it. Must invalidate if new subclass loads.
•Type profiling — Track which types actually appear at each call site. If always the same type (monomorphic), devirtualize optimistically.
•Guarded devirtualization — Emit a type check, and if it matches the expected type, use direct call; otherwise fall back to virtual dispatch.
•Inline caching — Cache the last type seen at each call site. Reuse if same type appears again.
•Final method optimization — Methods marked final cannot be overridden. Direct call is always safe.
•Escape analysis — If an object doesn't escape the current method, its exact type is known. Direct call is safe.

DevirtualizationExample
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// The JIT optimizer in action
 
interface Processor {
    int process(int value);
}
 
// Only implementation of Processor in the application
class Doubler implements Processor {
    @Override
    public int process(int value) {
        return value * 2;
    }
}
 
public class ProcessorClient {
    private final Processor processor;
    
    public ProcessorClient(Processor processor) {
        this.processor = processor;
    }
    
    public int processMany(int[] values) {
        int sum = 0;
        for (int v : values) {
            // Virtual call: processor.process(v)
            sum += processor.process(v);
        }
        return sum;
    }
}
 
// When this code runs:
// 1. JIT profiles the processMany() method
// 2. Observes that 'processor' is always Doubler
// 3. Applies guarded devirtualization:
 
// Optimized version (conceptual):
// public int processMany_optimized(int[] values) {
//     int sum = 0;
//     for (int v : values) {
//         if (processor.getClass() == Doubler.class) {  // Type guard
//             sum += v * 2;  // Inlined Doubler.process()!
//         } else {
//             sum += processor.process(v);  // Virtual fallback
//         }
//     }
//     return sum;
// }
 
// With Class Hierarchy Analysis, if Doubler is the ONLY Processor:
// public int processMany_cha(int[] values) {
//     int sum = 0;
//     for (int v : values) {
//         sum += v * 2;  // No guard needed, Doubler is the only option
//     }
//     return sum;
// }
 
// Tips to help the JIT devirtualize:
 
// 1. Use 'final' classes/methods when possible
final class FinalDoubler implements Processor {
    @Override
    public int process(int value) {
        return value * 2;
    }
}
 
// 2. Keep implementations monomorphic at call sites
// Avoid mixing types in the same collection if possible
 
// 3. Avoid unnecessary interface abstraction
// If only one implementation exists, consider concrete type

Help the JIT Help You

The Complete Method Resolution Flow

Let's trace a complete method call through the entire resolution process, from source code to executed instruction.

Converting Mermaid diagram...

Walking through both paths:

Non-Virtual Method (Static Binding):

Compiler sees call to non-virtual method
Overload resolution selects the method based on static types
Compiler emits CALL <function_address> with placeholder
Linker resolves placeholder to actual address
At runtime, CPU jumps directly to that address
Zero runtime overhead for dispatch

Virtual Method (Dynamic Binding):

Compiler sees call to virtual method
Overload resolution selects the signature based on static types
Compiler notes the vtable index for that method (e.g., index 0 for draw)
Compiler emits: load vptr, load vtable[0], call through pointer
At runtime:
- CPU fetches vptr from object (offset 0)
- CPU fetches function pointer from vtable[index]
- CPU calls through that pointer
JIT may devirtualize if type becomes known
Actual method executes

The Elegance of the Design

Summary: Understanding Call Resolution

We've traced the complete journey from method call to executed code. Here are the essential insights:

Key Takeaways

•Binding occurs at different times — Compile-time for overloading and non-virtual methods, runtime for virtual methods. Earlier binding means more optimization, later binding means more flexibility.
•Overload resolution uses static types — The compiler sees only declared types. Actual object types at runtime don't affect which overload is selected.
•Virtual dispatch uses dynamic types — At runtime, the vptr of the actual object determines which implementation runs, regardless of variable declaration.
•Static type limits what you can see — Only methods visible in the static type can be called. Dynamic type only affects which version of those methods runs.
•Hiding differs from overriding — Hiding uses static type (dangerous, often unintended). Overriding uses dynamic type (expected polymorphic behavior).
•JIT devirtualization bridges the gap — Modern runtimes convert virtual calls to direct calls when types are predictable, recovering static-dispatch performance.
•The vtable mechanism is elegant — One pointer per object, one table per class, two memory accesses per call. Simple, efficient, universal.

What's next:

Page Complete