This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Add object allocators to symbol and call summaries
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