[erlang-questions] Deterministic destruction of NIF resources

[Lukas Larsson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160717/de3e7fce/attachment.htm>