[erlang-questions] Why am I seeing RefcBinary with length < 64?

[Jan Chochol]

Hi,

It is possible that these binaries comes as part of larger binaries (also
called sub binaries).
Some information are available at
http://erlang.org/doc/efficiency_guide/binaryhandling.html .
Sub binaries only store reference to originating binary and length - it
also mean, that originating binary can not be freed.

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).

Regards,
Jan

On Wed, Dec 20, 2017 at 3:24 PM, Roger Lipscombe <roger@REDACTED>
wrote:

> Everything I've read on the subject of garbage collecting Erlang
> binaries says that binaries > 64 octets are stored off-heap.
>
> If I dump (using gdb and etp-offheapdump -- patched for 64-bits) the
> off-heap binaries for a given process, I get something like the
> following:
>
> [#RefcBinary<0x10,0x7f6b17079e08,0x7f6b39700560,0x7f6b39700578,(nil)>,
>  #RefcBinary<0x10,0x7f6b17079d68,0x7f6b39448c70,0x7f6b39448c88,(nil)>,
>  #RefcBinary<0xc,0x7f6b17079fb8,0x7f6c11c8c548,0x7f6c11c8c565,(nil)>,
>
> All in all, there are about 19.5K of them for this particular process.
> But they're all 0xc, 0x10 or 0x18 bytes in length.
>
> Mathematically astute readers will note that all three of those
> numbers are less than 64.
>
> Why are these binaries being stored off-heap? Is it bad? How do I make
> it store them in the process heap?
>
> Background: the process in question is a custom supervisor; it stores
> its children in a list of records; it starts processes in response to
> a gen_server:call from another node; the binaries are identifiable as
> the various startup arguments passed when starting the processes.
>
> Background background: we're running out of memory (the node hits ~9GB
> resident), either because the beam is hoarding binaries, or because
> the binary heap is hugely fragmented. I'm trying to figure out which
> and solve the problem.
> _______________________________________________
> 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/20171220/2aa4b5df/attachment.htm>