为何静态绑定方法不纳入类实例记录（CIR），编译器如何定位它？

Great question—this cuts right to how compilers handle method resolution and memory layout for class instances. Let’s break this down clearly, using Sebesta’s framework as a guide.

First: What is a Class Instance Record (CIR)? #

Think of a CIR as the memory blueprint for every instance of a class. It exists to hold two critical things:

• Instance-specific data (like a Car object’s vin or mileage values that vary per instance).
• References to methods that can’t be resolved at compile time—the dynamically bound ones.

Its core job is to give each object the runtime hooks it needs to behave correctly based on its type.

Why Statically Bound Methods Aren’t Stored in CIRs #

Statically bound methods (like non-virtual functions in C++, static methods in Java, or non-overridden Python methods) are fundamentally different from dynamic ones:

• They belong to the class, not individual instances: A statically bound method doesn’t depend on any instance state. Calling Math.abs() or FileUtils.deleteTempFiles() doesn’t require a specific object—these are class-level operations shared across all instances.
• Compile-time resolution eliminates CIR need: The compiler can figure out exactly which method to call before the program runs. It knows the method’s fixed memory address (usually in the program’s read-only code segment) and generates direct call instructions to that address. No runtime lookup via CIR is needed.
• Storing them in CIRs would waste memory: If every instance stored a pointer to the same static method, you’d duplicate the same reference hundreds or thousands of times for no reason. Static methods are shared, so there’s no need to tie them to individual CIRs.

How Compilers Find Statically Bound Methods Without CIRs #

The compiler uses simple, reliable tricks here:

1. Class name lookup: When you call a method with explicit class qualification (e.g., MyClass.staticMethod()), the compiler pulls the method’s address from the program’s symbol table (built during compilation) and hardcodes it into the executable.
2. Ignoring instances for static calls: Even if you mistakenly call a static method via an instance (like myObj.staticMethod() in Java), the compiler ignores the instance entirely. It still resolves the call to the class-level method, no CIR access required.
3. Fixed memory allocation: Statically bound methods live in a fixed code segment of the program’s memory. The compiler knows exactly where this segment lives, so it can generate direct jump/call instructions to the method’s location.

Why Dynamically Bound Methods Do Need CIRs #

Dynamically bound methods (like virtual functions in C++, overridden methods in Java/Python) rely on runtime polymorphism—meaning the actual method to call depends on the concrete type of the instance at runtime, not just its declared type in code.

• The compiler can’t know which implementation to call at compile time (e.g., a Animal reference could point to a Dog or Cat instance, each with a different makeSound() method).
• To handle this, the CIR stores a pointer to a method table (often called a vtable in C++). This table holds pointers to the actual method implementations for the instance’s concrete class.
• At runtime, when you call a dynamic method, the program uses the CIR’s method table pointer to look up the correct implementation—this is how polymorphism works under the hood.

内容的提问来源于stack exchange，提问作者Gagan Ganapathy