[erlang-questions] Deterministic destruction of NIF resources
Mon Jul 18 10:30:20 CEST 2016
They are often held by the repl. If one prints an allocated resource in
Erlang console it won't be released.
2016-07-17 10:37 GMT+03:00 Lukas Larsson <garazdawi@REDACTED>:
> On Sat, Jul 16, 2016 at 10:06 AM, Roger Lipscombe <roger@REDACTED>
>> In my testing, the destructor is delayed by a few seconds (when
>> repeatedly -- manually, so not particularly quickly -- restarting one
>> test process). In production, we're seeing the destructor being
>> delayed an arbitrarily long period, which is kinda important, because
>> the destructor is responsible for killing a background thread, and
>> we'd prefer it not to continue after the associated Erlang process has
>> As far as I can tell from reading the OTP source, it looks like
>> resources are allocated from the binary heap, rather than any
>> particular process heap, which suggests to me that they'll be
>> collected when the binary heap undergoes a GC. What triggers that?
> The binary heap never undergoes a gc, there is just the term heap gc. The
> binaries (which as you say include nif resources) are reference counted and
> de-allocated when all references are gone. I can't say for sure why your
> references are being held on for longer, if you want to dig deeper:
> * the sweep of the binaries is here:
> * the deletion of the process is here:
> * the calling of the destructor is done by erts_bin_free here:
> One of the great mantras of ERTS is "Why do it now when it would be
> cheaper/easier to do it later". So it may well be that something somewhere
> along the path delays and batches all the operations up.
> As Max says, in order to be sure when the release will happen. Release all
> references in the code and manually call the GC.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions