I think they are reference counted. From here Are NIF resources meant to be destroyed immediately on GC?
Sverker Eriksson
I fully agree with Jesper about not relying on GC for resource reclamation. An additional risk is that the resource does not get GC’ed at all if its reference has “leaked” away onto the heap of another process, like for example a logger or an io-server process.
So something could be keeping those references around.
@wanton7 and @tj0 I recent went through and fixed the memory leak issue, or rather the perceived leak issue.
I could not reproduce the leak, but, after reading through mailing lists and what not, the issue seemed to stem from the garbage collector not destructing the prepared statements in a timely manner. So instead, when ecto closes the connection we handle it by also releasing the underlying resource (the prepared statement) and then the destructor will run later and free the last remaining bytes that was a pointer to the prepared statement.
Overall this should suffice and would love to see if anyone who was having issues with memory growing like crazy during high load to give the latest release a try.