dyn Trait por dentro: el puntero gordo y la vtable

Un &dyn Resumir se escribe como una referencia normal, pero pesa el doble. No es un puntero cualquiera: es un puntero gordo (fat pointer), dos palabras de máquina en lugar de una. La primera apunta a los datos; la segunda, a una tabla de métodos que el compilador construyó para el par (tipo concreto, trait). Abrir esa caja —ver qué guarda la vtable y cómo se usa en cada llamada— es entender de verdad qué es un trait object.

Un puntero gordo: datos más vtable

Una referencia ordinaria &T es un puntero fino: una sola dirección de memoria, una palabra de máquina (8 bytes en 64 bits). Un trait object es distinto: mídelo y verás que ocupa el doble.

use std::mem::size_of;

trait Dibujar { fn dibujar(&self); }

fn main() {
    println!("{}", size_of::<&u8>());          // 8: puntero fino, una palabra
    println!("{}", size_of::<&dyn Dibujar>()); // 16: puntero gordo, dos palabras
}

Esos 16 bytes son dos punteros yuxtapuestos:

• Puntero a datos: la dirección del valor concreto —un Circulo, por ejemplo—, esté en la pila o en el heap.
• Puntero a vtable: la dirección de la tabla de métodos que corresponde al par (Circulo, Dibujar).

El tipo concreto ha desaparecido del sistema de tipos —a eso se le llama borrado de tipo (type erasure)—, pero no se ha perdido: su comportamiento vive ahora en la segunda mitad del puntero, en la vtable.

Qué guarda la vtable

La vtable es una estructura de punteros que el compilador genera una vez por cada par (tipo, trait) y coloca en memoria de solo lectura. Conceptualmente contiene esto —no es código que escribas, es lo que fabrica el compilador—:

// Disposicion conceptual de la vtable de (Circulo, Dibujar):
struct VTable {
    drop_in_place: fn(*mut ()),  // como destruir el valor concreto
    size: usize,                 // tamano en bytes del valor concreto
    align: usize,                // alineacion del valor concreto
    dibujar: fn(*const ()),      // puntero al metodo dibujar de Circulo
    // ...un puntero mas por cada metodo despachable del trait
}

Los tres primeros campos —destructor, tamaño y alineación— existen aunque el trait no tenga métodos: son los que permiten destruir correctamente un Box<dyn Dibujar>, llamando al destructor del tipo real, y saber cuánta memoria liberar. Después vienen los punteros a los métodos, uno por cada método despachable del trait, en un orden fijo que el compilador conoce.

Detalle clave: hay una sola vtable por par (tipo, trait), compartida por todos los trait objects de esa combinación. Un Vec con mil círculos tras dyn Dibujar tiene mil punteros a datos distintos, pero el mismo puntero a vtable repetido mil veces.

Puedes incluso observar que el tamaño viaja en la vtable: size_of_val sobre un trait object consulta el campo size de la tabla para responder en ejecución algo que, para un tipo concreto, se sabría en compilación.

use std::mem::size_of_val;

let c = Circulo { radio: 2.0 };
let obj: &dyn Dibujar = &c;
println!("{}", size_of_val(obj)); // lee 'size' de la vtable: el tamano real de Circulo

Sin ese campo, un Box<dyn Dibujar> no sabría cuánta memoria devolver al heap al destruirse. La vtable no es solo una tabla de métodos: es el mínimo de información sobre el tipo borrado que hace falta para usarlo y liberarlo con seguridad.

La llamada: una indirección más

Con esta estructura, obj.dibujar() no es una llamada directa, sino dos pasos:

let c = Circulo { radio: 2.0 };
let obj: &dyn Dibujar = &c;   // coercion: se adjunta la vtable de (Circulo, Dibujar)
obj.dibujar();                // 1) lee el puntero 'dibujar' de la vtable
                              // 2) salta a el, pasando el puntero a datos como self

Esa lectura del puntero en la tabla es la indirección del dispatch dinámico: un acceso a memoria extra frente a la llamada directa del código monomorfizado. En una CPU moderna, con la vtable caliente en caché y un predictor de saltos entrenado, su coste directo suele ser pequeño; lo caro, cuando lo es, es que el compilador no puede inlinar a través de ella ni optimizar el cuerpo del método en el contexto de la llamada.

flowchart LR
fp[Puntero gordo dyn Dibujar] --> d[Puntero a datos]
fp --> v[Puntero a vtable]
d --> val[Valor Circulo en memoria]
v --> tab[Tabla de metodos de Circulo y Dibujar]
tab --> drop[destructor]
tab --> size[tamano y alineacion]
tab --> met[puntero al metodo dibujar]
met --> val
style fp fill:#cba6f7,color:#11111b
style val fill:#a6e3a1,color:#11111b
style tab fill:#89b4fa,color:#11111b

La coerción a trait object: unsizing

¿De dónde sale el puntero a vtable? De una coerción que el compilador inserta al pasar de un tipo concreto a un dyn Trait. Se llama unsized coercion porque dyn Dibujar es un tipo de tamaño desconocido (?Sized): no sabes cuánto ocupa el valor real detrás de él, por eso siempre lo manejas tras un puntero —&dyn, Box<dyn>, Rc<dyn>—.

let c = Circulo { radio: 2.0 };

let r: &Circulo = &c;         // puntero fino: solo la direccion de c
let d: &dyn Dibujar = r;      // puntero gordo: direccion de c + vtable de (Circulo, Dibujar)

La coerción es de coste cero en sí misma: solo empaqueta el puntero que ya tenías junto con la dirección —conocida en compilación— de la vtable correcta. Ocurre automáticamente en las fronteras: al asignar a una variable &dyn, al pasar un argumento, al meter un Box::new(...) en un Vec<Box<dyn Dibujar>>.

La coerción también ocurre al pasar argumentos: si una función pide &dyn Dibujar y le das un &Circulo, el compilador inserta el unsizing en la frontera de la llamada.

fn pintar(obj: &dyn Dibujar) { obj.dibujar(); }

let c = Circulo { radio: 1.0 };
pintar(&c); // &Circulo se coacciona a &dyn Dibujar aqui, en la llamada