Are NIF resources meant to be destroyed immediately on GC?

[Sverker Eriksson]

Prior to OTP 22.0 resource destructors were called directly by the thread that happened to decrease the reference counter down to zero.

>From OTP 22.0 resource destructors are scheduled. This in order to ensure a stable known execution context for the destructor callback. So it may not have executed when erlang:garbage_collect  returns, but will very soon (unless you have a very overloaded system or a bug preventing ref counter from reaching zero).

 

To not get dependent on the garbage collector to release large memory blocks (or other limited OS resources) you can solve it (like a lot of other problems) with an extra level of indirection. Keep the resource object small and allocate the large block separately. Then you can deallocated the big block whenever you want and mark the resource as dead with a NULL pointer for example.

 

/Sverker, Erlang/OTP

 

 

From: erlang-questions <erlang-questions-bounces@REDACTED> On Behalf Of José Valim
Sent: den 23 november 2020 20:24
To: Erlang <erlang-questions@REDACTED>
Subject: Are NIF resources meant to be destroyed immediately on GC?

 

Hi everyone,

 

We are working on some code that allocates large chunks of memory inside a NIF and ties them to a resource (using enif_alloc_resource + enif_make_resource). While running some tests, I noticed that we were holding onto these resources for longer than we wanted to, so we have added calls to erlang:garbage_collect/1. In a nutshell, the code looks like this:

 

my_nif:function_allocates_large_memory(),

erlang:garbage_collect(),

my_nif:check_if_resource_has_been_destroyed().

 

In our runs, it seems that the resource has not yet been destroyed in most cases. However, if we do add a sleep after garbage collection, then the odds of it being destroyed increases as we increase the sleep interval.

 

Is this correct? Even if the resource was garbage collected, the destructor may not have been called? Or is this actually a big in our software that we should look deeper into?

 

Thank you,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201123/10697c5e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5509 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201123/10697c5e/attachment.bin>