[erlang-questions] Deterministic destruction of NIF resources

[John Doe]

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>
> wrote:
>
>>
>> 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
>> died.
>>
>> 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:
> https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L11674
> * the deletion of the process is here:
> https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L12857
> * the calling of the destructor is done by erts_bin_free here:
> https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_message.c#L171
>
> 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.
>
> Lukas
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160718/9780e1b3/attachment.htm>