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

[Lukas Larsson]

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

> On 20 December 2017 at 14:32, Jan Chochol <jan.chochol@REDACTED>
> wrote:
> > Hi,
> >
> > It is possible that these binaries comes as part of larger binaries (also
> > called sub binaries).
>
> Is there any way to figure this out in gdb?
>

You have to check the size in the ProcBin vs the size of the Binary. The
Binary is what is pointed to by the second to last pointer value in the
dump.

eg:

(gdb) etp-offheapdump ((Process*)0x7fffb53852d8)->off_heap.first
warning: Expression is not an assignment (and might have no effect)
% Offheap dump:
[#RefcBinary<0x3,0x7fffb1cc2460,0x7fffb1841aa8,0x7fffb1841ac0,(nil)>,
 #RefcBinary<0x1f,(nil),0x7fffb1841618,0x7fffb1841630,(nil)>].
(gdb) p *((Binary*)0x7fffb1841aa8)
$1 = {intern = {flags = 0, refc = {counter = 1}}, orig_size = 3, orig_bytes
= "1"}

and yes, that size can be smaller than 64 bytes. These < 64 byte binaries
are created by the runtime when it needs a binaries that a GC will not move
for whatever reason. One such example would be
unicode:characters_to_binary/2, which is the reason why the example above
only has a 3 byte refc. I'm sure there are others as well. I'm not sure if
I consider this a bug or not, but it's definitely not optimal behavior.

Lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171220/6d65e48c/attachment.htm>