<div dir="ltr">They are often held by the repl. If one prints an allocated resource in Erlang console it won't be released.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-17 10:37 GMT+03:00 Lukas Larsson <span dir="ltr"><<a href="mailto:garazdawi@gmail.com" target="_blank">garazdawi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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></span><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" target="_blank">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" target="_blank">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" target="_blank">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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Lukas</div></font></span></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>