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