<div dir="ltr">Hi,<div><br></div><div>It is possible that these binaries comes as part of larger binaries (also called sub binaries).</div><div>Some information are available at <a href="http://erlang.org/doc/efficiency_guide/binaryhandling.html">http://erlang.org/doc/efficiency_guide/binaryhandling.html</a> .</div><div>Sub binaries only store reference to originating binary and length - it also mean, that originating binary can not be freed.</div><div><br></div><div>You can use binary:copy/1 to convert sub binary to fresh new binary (witch will be stored on heap in case of small binaries).</div><div><br></div><div>Regards,</div><div>Jan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 20, 2017 at 3:24 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Everything I've read on the subject of garbage collecting Erlang<br>
binaries says that binaries > 64 octets are stored off-heap.<br>
<br>
If I dump (using gdb and etp-offheapdump -- patched for 64-bits) the<br>
off-heap binaries for a given process, I get something like the<br>
following:<br>
<br>
[#RefcBinary<0x10,<wbr>0x7f6b17079e08,0x7f6b39700560,<wbr>0x7f6b39700578,(nil)>,<br>
 #RefcBinary<0x10,<wbr>0x7f6b17079d68,0x7f6b39448c70,<wbr>0x7f6b39448c88,(nil)>,<br>
 #RefcBinary<0xc,<wbr>0x7f6b17079fb8,0x7f6c11c8c548,<wbr>0x7f6c11c8c565,(nil)>,<br>
<br>
All in all, there are about 19.5K of them for this particular process.<br>
But they're all 0xc, 0x10 or 0x18 bytes in length.<br>
<br>
Mathematically astute readers will note that all three of those<br>
numbers are less than 64.<br>
<br>
Why are these binaries being stored off-heap? Is it bad? How do I make<br>
it store them in the process heap?<br>
<br>
Background: the process in question is a custom supervisor; it stores<br>
its children in a list of records; it starts processes in response to<br>
a gen_server:call from another node; the binaries are identifiable as<br>
the various startup arguments passed when starting the processes.<br>
<br>
Background background: we're running out of memory (the node hits ~9GB<br>
resident), either because the beam is hoarding binaries, or because<br>
the binary heap is hugely fragmented. I'm trying to figure out which<br>
and solve the problem.<br>
______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>