[erlang-bugs] erts_debug:flat_size/1 wrong?

Anthony Ramine n.oxyde@REDACTED
Sun Sep 28 14:28:18 CEST 2014


While we are at it, I would like erts_debug to be a proper module, with a module_info function etc.

Le 28 sept. 2014 à 09:00, Robert Virding <rvirding@REDACTED> a écrit :

> Perhaps an easy solution would be to document, unofficially of course so it is not doucmented, exactly how erts_debug:flat_size/1 works.
> 
> Robert
> 
> 
> On 26 September 2014 11:27, Michael Truog <mjtruog@REDACTED> wrote:
> On 09/26/2014 06:46 AM, Sverker Eriksson wrote:
>> 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 
> 
> Thank you for the information.  However, based on this the Efficiency Guide memory information should be slightly wrong (at http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923), since the information should be
> * List: 1 word + 2 word per element + the size of each element
> * Tuple: 2 words + 1 word per element + the size of each element
> 
> and not what it currently is:
> * List: 1 word + 1 word per element + the size of each element
> * Tuple: 2 words + the size of each element
> 
> That is at least what I have found when using erts_debug:flat_size/1 in the repo https://github.com/okeuday/erlang_term when looking at the total size of an Erlang term.  Do you agree?
> 
> Thanks,
> Michael
>> 
>> 
>> /Sverker, Erlang/OTP 
>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
> 
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs




More information about the erlang-bugs mailing list