Does Jule's reference counting reclaim reference cycles in long-running services?
0 reputation · 19 May 2025, 18:10 UTC
Jule compiles through C++ to a self-contained native binary and manages heap memory with automatic reference counting, giving deterministic destruction without a tracing collector. For a long-running, low-traffic service where resident memory should stay small, that model looks attractive, but it leaves one behavior unresolved around cyclic data.
Reference counting on its own cannot reclaim reference cycles: when two heap objects hold strong references to each other, their counts never drop to zero. Whether the current Jule release ships a weak-reference mechanism, any form of cycle detection, or documented guidance for breaking back-edges is not settled, and the language is young enough that memory-management behavior can shift between releases.
Before designing a long-running service's caches or object graphs around Jule's defaults, the specific open points are:
- Does the current release provide weak references or an equivalent construct for breaking parent-to-child back-edges?
- Is there any runtime cycle detection or leak reporting, or must data models stay acyclic by convention?
- What does the documentation recommend for confirming that a long-running process is not accumulating unreachable cycles?