forked from okeuday/erlang_term
-
Notifications
You must be signed in to change notification settings - Fork 0
/
erlang_bugs_email.txt
69 lines (61 loc) · 2.22 KB
/
erlang_bugs_email.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
Delivered-To: mjtruog at gmail dot com
Return-Path: <sverker.eriksson at ericsson dot com>
Date: Fri, 26 Sep 2014 15:46:44 +0200
From: Sverker Eriksson <sverker.eriksson at ericsson dot com>
To: Michael Truog <mjtruog at gmail dot com>
CC: <erlang-bugs at erlang dot org>
Subject: Re: [erlang-bugs] erts_debug:flat_size/1 wrong?
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: sverker.eriksson at ericsson dot com
On 09/26/2014 04:19 AM, Michael Truog wrote:
> Hi,
>
> I have been attempting to compare the output of erts_debug:flat_size/1
> to the memory info at
> http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923 and
> the results show that each term's size is off-by-one (at least for
> pids local/remote, refs local/remote, floats, integers, bignums,
> binaries and atoms). I know the function is experimental, but this is
> a bug, right? The problem affects top-level terms and nested terms,
> so it is likely to understate the memory with large terms. I wanted
> to make sure the memory info (in the efficiency guide) was accurate
> (it seems like it is). I was testing with R16B03 on 64bits.
>
> For example:
> 1> erts_debug:flat_size(576460752303423488).
> 2
> 2> erts_debug:flat_size(576460752303423487).
> 0
> 3> erts_debug:flat_size(undefined).
> 0
> 4> erts_debug:flat_size([]).
> 0
> 5> erts_debug:flat_size([undefined]).
> 2
> % 1 word for each element in the list * 2 elements including []
> 6> erts_debug:flat_size(erlang:make_ref()).
> 3
> 7> erts_debug:flat_size(erlang:self()).
> 0
> 8> erts_debug:flat_size(1.0).
> 2
>
erts_debug:flat_size/1 is undocumented and can therefor not be wrong by
definition :-)
But no, there is no bug, erts_debug:flat_size/1 works as intended in the
current implementation. It returns the number of words on the _heap_
occupied (*) by the term. Excluded are thus off-heap data such as
binaries larger than 64 bytes AND the top term word, which is kept in a
register or on the stack.
(*) erts_debug:flat_size does not take sharing of sub-terms into account
while erts_debug:size/1 do.
1> A = "Hello".
"Hello"
2> erts_debug:flat_size(A).
10
3> erts_debug:flat_size({A,A}).
23
4> erts_debug:size({A,A}).
13
/Sverker, Erlang/OTP