La verificación de funciones sin asignaciones de OxCaml que más lenguajes deberían aprender

• OxCaml, el superconjunto de OCaml de Jane Street, permite declarar al compilador con [@zero_alloc] la prohibición de asignaciones en el heap en todo el árbol de llamadas de una función
• Si aparece una asignación en la ruta de llamadas declarada, queda expuesta de inmediato como un fallo de compilación, lo que permite evitar regresiones más rápido que buscarlas después con un profiler
• En C, C++, Java, Go, C#, Rust, Zig, OCaml y otros, el enfoque principal suele ser encontrar y reducir con un profiler las asignaciones en hot paths
• En el código de hot paths, incluso un cambio pequeño puede volver a introducir asignaciones; si se olvida el contexto de la optimización previa, se termina repitiendo la misma investigación
• Las convenciones de pasar allocators en Zig o en algunas partes del Rust moderno también ayudan, pero una verificación del compilador es una protección más directa que una convención

---

Cómo [@zero_alloc] cambia la gestión de asignaciones

• OxCaml es un superconjunto de OCaml de Jane Street y admite afirmar que una función no asigna en el heap
• Al agregar [@zero_alloc] a una función, el compilador verifica si hay asignaciones en el heap no solo en esa función, sino también en todo el árbol de llamadas por debajo de ella
• Si ocurre una asignación dentro del árbol de llamadas, el build falla y el compilador informa dónde se produjo la asignación
• Aunque sería posible crear verificaciones similares mediante análisis estático, según el resumen generado son pocos los lenguajes mainstream que incorporan este tipo de funcionalidad directamente en el compilador

Diferencia frente al enfoque centrado en profilers

• En otros lenguajes, lo habitual es encontrar asignaciones con un profiler y luego eliminar o reducir especialmente las asignaciones dentro de loops que se ejecutan millones de veces
• C, C++, Java, Go, C#, Rust, Zig, OCaml y otros se enumeran como ejemplos del enfoque centrado en profilers
• Cambiar una sola línea en un hot path puede volver a introducir asignaciones, y para encontrar la causa hay que volver al profiler
• En Zig o en algunas partes del Rust moderno, se pueden reducir regresiones evitando pasar un allocator a las funciones, pero esto depende de una convención
• La diferencia de [@zero_alloc] está en que no se basa en análisis posterior ni en reglas de equipo, sino en que el compilador bloquea las regresiones de asignación en el momento del build

[GN⁺]

Comentarios en Lobste.rs

• Entendía que en Zig la razón para pasar el allocator como argumento de una función era impedir que las funciones que no reciben un allocator como argumento pudieran hacer asignaciones en el heap; me pregunto si eso es correcto.
  Si de verdad es cierto que “las convenciones pueden ignorarse”, parece distinto de la intención original.

  • Sí, al final es solo una convención.
    Incluso dentro de una función se puede crear un allocator nuevo, igual que se haría afuera.

• enlace de regalo: https://theconsensus.dev/p/2026/…

  • D tiene nogc desde hace bastante tiempo, y creo que tiene una semántica similar en el sentido de que el GC se encarga de las asignaciones.
    https://dlang.org/phobos/dmd_nogc.html
    En algún momento también se agregaron de forma experimental excepciones nogc, pero no he revisado su estado actual ni la implementación.
    https://dlang.org/changelog/2.079.0.html#dip1008

• En Rust, usar solo core también es una forma de evitar asignaciones.

  • “Evitar asignaciones” es solo una parte de la historia.
    Ese enfoque termina siendo más bien “controla tus dependencias” o “revisa manualmente todo el grafo de llamadas”.
    El foco del artículo está en cómo una herramienta, como el compilador, puede imponer estáticamente cierta propiedad y ofrecer un flujo de trabajo para encontrar de manera productiva los puntos donde esa propiedad se rompe.

• D tiene @nogc, y después el asunto es usar únicamente abstracciones que se puedan controlar directamente y que tengan patrones de asignación claros.

• Como parece que se perdió la capacidad de poner títulos descriptivos a los artículos, agrego esto: lo central es una función que permite marcar una función con [@zero_alloc] y hacer que el compilador rechace el programa si el árbol de llamadas de esa función toca el heap.

• Me pregunto si este enfoque también podría aplicarse a varias condiciones como “no lanza excepciones ni hace panic”, “sin locks” o “siempre termina”.