Does marking a seq of objects with destructors as `acyclic` prevent memory leaks in cyclic references?

The Short Answer

No, marking a type as acyclic does not prevent memory leaks in cyclic references. In fact, it does the opposite: it instructs the garbage collector to skip cycle detection for that type. If a cycle actually exists, the collector will ignore it, and the objects—along with their =destroy destructors—will never be reclaimed, resulting in a permanent memory leak.

Mechanism and Risks

Under the ORC garbage collector, the acyclic pragma is an optimization hint. It tells the system: "This type is guaranteed never to be part of a reference cycle."

• Confirmed Behavior: When the collector encounters a type marked acyclic, it bypasses the expensive cycle-detection phase.
• The Failure Mode: If you mark a seq as acyclic but it participates in a cycle (e.g., an element in the sequence holds a reference back to the sequence itself), the collector assumes no cycle exists. The reference counts will never reach zero, and the cycle collector will not intervene to break the loop.
• Destructor Impact: Because the objects are never reclaimed, the =destroy method is never called. This leads to both memory leaks and the failure to release any external resources (file handles, sockets) managed by the destructor.

Recommended Patterns for Deterministic Cleanup

To ensure memory is reclaimed and destructors execute deterministically without relying on the non-deterministic cycle collector, consider these alternatives:

1. Explicit Deallocation: Implement a manual dealloc() or clear() method that explicitly breaks the cycles (setting references to null) before the object goes out of scope.
2. Ownership Hierarchy: Use a DoublyLinkedList pattern where only the parent owns the children, and children use "weak" or non-owning references to the parent.
3. Manual Cycle Collection: If the architecture requires complex cycles, avoid acyclic and trigger the cycle collector manually at known safe points in the application lifecycle.

Empirical Verification

To verify that your chosen approach does not leak in long-running workloads, use the following scoped verification steps:

• Destructor Logging: Add a unique identifier and a timestamp log inside the =destroy method. If you drop all root references to a sequence but the log does not trigger, you have a leak.
• Heap Monitoring: Run the workload in a loop that creates and discards cyclic sequences. Monitor the resident set size (RSS). A linear increase in memory usage indicates that acyclic is masking a leak.
• Comparison Test: Run the same workload with and without the acyclic pragma. If memory usage is lower without the pragma, the cycle collector was successfully reclaiming objects that acyclic was hiding.

Missing Diagnostic Detail: To refine this recommendation, are the cycles created dynamically at runtime via user input, or are they static architectural relationships defined at compile time?