Automatic Reference Counting: el compilador que cuenta por ti

El nombre engaña por partida doble. Automatic sugiere un servicio que corre mientras tu programa vive, inspeccionando el montículo; Counting sugiere una contabilidad que alguien lleva aparte, en tiempo de ejecución. Ninguna de las dos cosas es exacta. ARC es una transformación del compilador: al generar el código intermedio, Swift analiza el flujo de tus referencias y escribe por ti las llamadas a swift_retain y swift_release que en Objective-C tenías que escribir a mano. Lo automático es la escritura, no la vigilancia. Y de ese matiz —la decisión se toma en compilación, el efecto ocurre en ejecución— se deducen las tres propiedades que definen el modelo: su determinismo, su coste distribuido y su único agujero.

El contrato de propiedad

Toda instancia de clase vive en el montículo precedida por una cabecera de dos palabras: un puntero a los metadatos del tipo y un campo de estado que aloja los conteos. El conteo fuerte responde a una pregunta muy concreta y muy pequeña: cuántas referencias se han comprometido a mantener viva esta instancia. No cuántas la conocen, ni cuántas la usan: cuántas la sostienen. Cuando ese número llega a cero, la destrucción es inmediata y en el mismo hilo: se ejecuta deinit, se liberan las propiedades almacenadas y la memoria vuelve al asignador.

final class Nodo {
    let id: Int
    init(id: Int) { self.id = id }
}

func inspeccionar(_ n: Nodo) { _ = n.id }   // parametro prestado

func demo() {
    let a = Nodo(id: 1)   // el inicializador entrega la instancia con conteo 1
    let b = a             // retain: conteo 2
    inspeccionar(b)       // convencion prestada: no toca el conteo
}                         // dos release al cerrar el ambito: conteo 0

La clave está en la tercera línea, que es la que casi nadie predice bien. Pasar una referencia a una función no incrementa el conteo, porque los parámetros se pasan por defecto con la convención prestada: el llamador garantiza que la instancia seguirá viva durante toda la llamada, de modo que el llamado puede usarla sin pagar nada. Solo los valores poseídos —lo que devuelve un inicializador, lo que se almacena en una propiedad, lo que se guarda en una colección— generan tráfico de conteo. Desde Swift 5.9 puedes hacer explícita esa distinción con los modificadores borrowing y consuming, que dejan de ser un detalle interno del compilador para convertirse en parte de la firma.

func observar(_ n: borrowing Nodo) { }   // prestado: cero retain, cero release
func absorber(_ n: consuming Nodo) { }   // poseido: el llamado libera al terminar

La cabecera, además, no guarda un solo número. Junto al conteo fuerte conviven un conteo de referencias no propietarias y, cuando hace falta, un puntero a una tabla lateral donde se registran las débiles. Los tres miden cosas distintas y se agotan en momentos distintos: el fuerte decide cuándo se ejecuta deinit, el no propietario decide cuándo la memoria vuelve al asignador y el débil decide cuándo puede desaparecer la tabla auxiliar. Que sean tres relojes y no uno explica buena parte de los fenómenos que parecen contradictorios al depurar, y es el material de las dos lecciones siguientes.

Conviene fijar una consecuencia que se olvida a menudo: ARC no gobierna las estructuras ni los enumerados, porque esos no viven necesariamente en el montículo ni tienen identidad. Lo que sí ocurre es que una estructura cuyos campos son referencias arrastra el coste de todos ellos: copiarla implica un retain por cada campo de referencia que contenga.

Determinismo frente a trazado

Un recolector de basura clásico responde a la pregunta contraria. En lugar de contar quién sostiene qué, parte de un conjunto de raíces —pila, registros, variables globales— y recorre el grafo marcando lo alcanzable; lo que no se alcanza se recicla. La literatura de recolección demostró hace tiempo que ambas técnicas no son rivales sino duales: el trazado calcula la alcanzabilidad y el conteo calcula su complemento, y cualquier recolector real es una combinación de las dos. Elegir una u otra no es elegir una implementación más rápida, es elegir qué garantías da el lenguaje.

Hay una segunda diferencia menos comentada y igual de importante: bajo trazado, la memoria libre es un recurso que el recolector necesita para ir rápido, de modo que el rendimiento mejora cuando el proceso dispone de holgura. En un dispositivo con memoria limitada y muchos procesos compitiendo, esa holgura no existe, y ese fue uno de los argumentos técnicos que llevaron a la plataforma a quedarse con el conteo.

El determinismo no es un detalle estético: es lo que permite que deinit sirva para algo. Si un objeto cierra un descriptor de fichero, suelta un bloqueo o cancela una suscripción, necesitas saber cuándo ocurre eso, y bajo trazado la respuesta honesta es “en algún momento, quizá nunca antes de que el proceso termine”. ARC convierte la liberación de recursos en una propiedad del ámbito léxico, que es exactamente el patrón que en la tradición de C++ se llama adquisición es inicialización.

El precio de esa garantía es igual de concreto. Un conteo local no puede detectar que dos objetos se sostienen mutuamente, porque desde dentro del ciclo cada uno ve un conteo legítimamente mayor que cero. Esa isla es inalcanzable desde cualquier raíz y aun así permanece viva: es la fuga de memoria canónica de ARC, y es el tema de la lección siguiente.

flowchart TB
a[Inicializador entrega la instancia con conteo uno] --> b[Nueva referencia fuerte inserta retain]
b --> c[El conteo sube]
c --> d[Una referencia sale de ambito e inserta release]
d --> e[El conteo baja]
e --> f[Conteo cero: se ejecuta deinit]
f --> g[Se liberan las propiedades almacenadas]
g --> h[La memoria vuelve al asignador]
e --> c

Lo que cuesta contar

Un retain no es una suma: es una suma atómica. Como cualquier hilo puede tomar o soltar una referencia en cualquier momento, el conteo debe modificarse con operaciones de lectura y escritura entrelazadas, lo que implica barreras de memoria y, bajo contención real, invalidación de líneas de caché entre núcleos. Ese es el coste que aparece en los perfiles cuando el bucle caliente manipula objetos: no una fuga, sino tráfico de ARC.

Ese coste tiene una asimetría que conviene conocer: el caso sin contención es relativamente barato, del orden de unas pocas decenas de ciclos, mientras que el caso con varios núcleos tocando el mismo objeto se dispara, porque cada modificación obliga a los demás a recargar la línea de caché. De ahí una consecuencia práctica que sorprende a quien viene de otros lenguajes: compartir un objeto entre hilos no solo cuesta sincronización lógica, cuesta también tráfico de conteo.

Contra eso trabaja el optimizador. Su labor consiste en demostrar que ciertos pares retain y release son redundantes —porque otra referencia ya garantiza la vida del objeto en ese intervalo— y eliminarlos. Además, las conformidades no genéricas, las llamadas a métodos final y las funciones internas dentro de un módulo compilado como unidad permiten al compilador ver el flujo completo y borrar mucho más.

// Deja que ARC vea la unicidad: base del copy-on-write
struct Buffer {
    private var almacen: Almacen

    mutating func escribir(_ x: Int) {
        if !isKnownUniquelyReferenced(&almacen) {
            almacen = almacen.copia()   // solo si alguien mas lo sostiene
        }
        almacen.datos.append(x)
    }
}

isKnownUniquelyReferenced es el punto donde el conteo deja de ser un detalle invisible y pasa a ser una decisión de diseño: preguntar si eres el único dueño es lo que convierte una estructura con almacenamiento en el montículo en un tipo de valor de verdad. En el extremo opuesto están Unmanaged y las referencias sin gestionar, que apagan el conteo por completo a cambio de que tú respondas por la vida del objeto; herramientas legítimas para un puñado de casos medidos, y una forma rápida de escribir errores de memoria en todos los demás.

Dónde aparece ARC sin que lo veas

La cuenta no se limita a las clases que tú declaras. Un closure que escapa es también un objeto del montículo: contiene un puntero a código y una caja con lo capturado, tiene su propio conteo y retiene todo lo que capturó de forma fuerte. Guardar un closure en una propiedad es, a efectos de memoria, guardar un objeto que a su vez guarda otros; por eso los ciclos con closures son tan frecuentes y por eso el tamaño de lo capturado importa.

También aparece en los existenciales. Cuando escribes any Protocolo, el valor viaja en un contenedor de tamaño fijo; si el tipo concreto no cabe, se guarda en una caja del montículo con conteo propio, de modo que copiar el existencial deja de ser mover bytes y pasa a ser una retención. Lo mismo ocurre con los enumerados marcados indirect, con las cadenas y colecciones no pequeñas, y con cualquier tipo que internamente delegue su almacenamiento en una referencia compartida.

protocol Forma { func area() -> Double }
struct Poligono: Forma {                 // grande: no cabe en el contenedor
    var vertices: [CGPoint]
    func area() -> Double { 0 }
}

let sueltas: [any Forma] = [Poligono(vertices: [])]  // caja con conteo propio
let cerradas: [Poligono] = [Poligono(vertices: [])]  // sin existencial, sin caja

Queda un origen que se olvida siempre: la interoperabilidad con Objective-C. Los métodos importados que devuelven objetos siguen la convención de autoliberación, así que la instancia no se libera al terminar la llamada sino cuando se vacía el charco correspondiente, normalmente al final de la iteración del bucle de eventos. En un bucle cerrado que crea muchos objetos importados, eso produce un perfil de memoria que sube en diente de sierra y que se confunde con una fuga sin serlo.