Add object allocators to symbol and call summaries

[Martin Liška]

On 11/5/19 3:48 PM, Jan Hubicka wrote:
>>>
>>> stringpool.c:63 (alloc_node)                            47M:  2.3%        0 :  0.0%        0 :  0.0%        0 :  0.0%     1217k
>>> ipa-prop.c:4480 (ipa_read_edge_info)                    51M:  2.4%        0 :  0.0%      260k:  0.0%      404k:  0.3%      531k
>>> hash-table.h:801 (expand)                               81M:  3.9%        0 :  0.0%       80M:  4.7%       88k:  0.1%     3349
>>>    ^^^ some of memory comes here which ought to be accounted to caller of
>>>    expand.
>>
>> Yes, these all come from ggc_internal_alloc. Ideally we should register a mem_alloc_description
>> for each created symbol/call_summary and register manually every allocation to such descriptor.
> 
> Or just pass memory stats from caller of expand and transitively pass it
> from caller of summary. This will get us the line info of get_create
> call that is IMO OK.

The issue with this approach is that you will spread a summary allocation
along all the ::get_create places. Which is not ideal.

>>> lto/lto-common.c:204 (lto_read_in_decl_state)          200M:  5.8%        0 :  0.0%       65M:  2.2%       19M:  6.1%     1731k
>>> ipa-prop.c:4478 (ipa_read_edge_info)                   210M:  6.1%        0 :  0.0%     1361k:  0.0%       17M:  5.7%     1171k
>>>     ^^^ those are jumptables that ought to be freed too.
>>
>> I verified this and I can confirm that
>>
>> class GTY((for_user)) ipa_edge_args
>> {
>>   public:
>>
>>    /* Default constructor.  */
>>    ipa_edge_args () : jump_functions (NULL), polymorphic_call_contexts (NULL)
>>      {}
>>
>>    /* Destructor.  */
>>    ~ipa_edge_args ()
>>      {
>>        vec_free (jump_functions);
>>        vec_free (polymorphic_call_contexts);
>>      }
>>
>> is called which then calls vec_free. I traced that down and m_reverse_object_map does not
>> contain the pointer. So some minor issue in allocation tracing. But I'm pretty sure the memory
>> is released.
> 
> Well, it is not very minor given that it is third largest allocation. It
> would be nice to track this down so we can trust the summaries again.
> It is very strange that overhead gets registered but never unregistered
> - both freeing or garbage collecting should do that.
> 
> I will try to see what happens.

Try to take a look, or we can debug that on Thursday together?
Martin

> 
> Honza
>>
>> Martin
>>
>>>
>>> cgraph.c:851 (create_edge)                             285M:  8.3%        0 :  0.0%       33M:  1.1%        0 :  0.0%     3141k
>>> cgraph.h:2712 (allocate_cgraph_symbol)                 417M: 12.1%        0 :  0.0%      121M:  4.0%        0 :  0.0%     1567k
>>> tree-streamer-in.c:631 (streamer_alloc_tree)           758M: 22.0%       96M: 23.0%     1267M: 41.7%       64M: 20.6%       15M
>>> --------------------------------------------------------------------------------------------------------------------------------------------
>>> GGC memory                                              Leak          Garbage            Freed        Overhead            Times
>>> --------------------------------------------------------------------------------------------------------------------------------------------
>>> Total                                                 3453M:100.0%      418M:100.0%     3039M:100.0%      313M:100.0%       49M
>>> --------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> I am not sure where the problem is - it is GGC memory and we release
>>> those summaries after inlining so there should not be any pointers to
>>> them. At worst it should account to garbage, so it may be also some
>>> accounting bug.
>>>
>>> I suppose first thing to try is to breakpoint in the ggc walker of these
>>> and see if it shows up in the final ggc.
>>>
>>> Honza
>>>
>>