Additionally, these shared references are refcounted by processes that have ever accessed them.

So it is safe and cheap to pass them through function parameters, and safe and cheap to send them between processes, but dangerous to handle them in long-running processes as the long-lived process will cause the reference to be held, filling up RAM with your large binary, which cannot be reclaimed without manual intervention. At least not until every process that has ever handled them has died. For a recent thread on this phenomenon with detection, remediation, and other tips check out Agent keeps large binary memory despite no state .

If the process reading from your NIF is short-lived, you will be fine; if it’s a GenServer you may want to spin up a worker process on demand to do the actual handling to prevent memory bloat. Phoenix uses short-lived processes per-request so that process boundary should be fine to handle large binaries.

Thanks for all the answers, short and detailed ones.

Indeed, my NIF function is a short-living one, I think I’m safe here.

Again, this forum is great thanks to you all nice folks. Have a nice day !

Large binaries (> 64 byte or so) are passed by reference. Small binaries by value.

Only exception, the small binarie is a substring of a large binarie, in that case a fat pointer is passed, hindering the original binary from garbage collection as long as the substring is “alive”, thats why many slicing operations have a :copy option.

The only “expensive” action is to send them over a network.

If we are talking about large nested data structures (maps + lists) then sending them across processes might already be expensive, as this involves a deep copy!

Binaries are the only datatype that exists on a “shared” heap.