<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 16, 2016 at 10:06 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>In my testing, the destructor is delayed by a few seconds (when<br>
repeatedly -- manually, so not particularly quickly -- restarting one<br>
test process). In production, we're seeing the destructor being<br>
delayed an arbitrarily long period, which is kinda important, because<br>
the destructor is responsible for killing a background thread, and<br>
we'd prefer it not to continue after the associated Erlang process has<br>
died.<br>
<br>
As far as I can tell from reading the OTP source, it looks like<br>
resources are allocated from the binary heap, rather than any<br>
particular process heap, which suggests to me that they'll be<br>
collected when the binary heap undergoes a GC. What triggers that?<br></blockquote><div><br></div><div>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:</div><div><br></div><div>* the sweep of the binaries is here: <a href="https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L11674">https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L11674</a></div><div>* the deletion of the process is here: <a href="https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L12857">https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L12857</a></div><div>* the calling of the destructor is done by erts_bin_free here: <a href="https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_message.c#L171">https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_message.c#L171</a></div><div><br></div><div>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.</div><div><br></div><div>As Max says, in order to be sure when the release will happen. Release all references in the code and manually call the GC.</div><div><br></div><div>Lukas</div></div></div></div>