Deep Dive into Reference Counting & FFI Security

Tracing Garbage Collectors (like the ones in V8 or JVM) are miraculous for product development, but they introduce non-deterministic garbage collection sweeps, high heap footprint, and complete friction when writing modules with C++, C or Rust.

During Dryad's design, our runtime team decided to place a Reference Counting (RC) allocator at the very core of the memory engine, heavily inspired by Rust's Rc and Swift's ARC.

In practice, this means each allocated value keeps an internal counter of active references. The moment the last reference goes out of scope, the value is destroyed immediately and its memory is reclaimed — no stop-the-world sweeps, no generations, no complex write barriers.

However, reference counting has a well-known weakness: it can't handle cyclic references. If object A references B and B references A, neither will ever drop to zero, leaking memory. For Dryad's first version, we accept this trade-off. Users are encouraged to use weak reference patterns when cycles are likely.

For FFI safety, every native pointer coming from C or Rust is wrapped in an opaque handle inside Dryad's runtime. You never manipulate raw addresses from Dryad code directly. The runtime validates each handle before dereferencing, preventing use-after-free and double-free vulnerabilities at the language boundary.

This combination gives us predictable latency (no GC pauses), C++/Rust-friendly memory layout, and safe interop by default.