On Tue, Nov 18, 2014 at 07:59:26PM +0100, Jan Hubicka wrote:
Hi,
On Tue, Nov 18, 2014 at 04:39:00PM +0100, Jan Hubicka wrote:
On Fri, Nov 14, 2014 at 08:59:10PM +0100, Jan Hubicka wrote:
b) with GTY, we cannot call destructor
Everything in symbol table is expecitely memory managed (i.e. enver left
to be freed by garbage collector). It resists in GTY only to allow linking
garbage collected object from them and to get PCH working.
Well, if I understand the intent correctly, summaries are for stuff
that is not in the symbol table. For example jump functions are a
Correct.
vector of structures possibly containing trees, so everything has to
be in garbage collected memory.
When an edge is removed, it is necessary to be notified about it
immediately, for example to decrement rdesc_refcount (you might argue
that that should be done in a separate hook and not from within a
summary class but then you start to rely on hook invocation ordering
so I think it is better to eventually use the summaries for it too).
I do not see why ctors/dtors can not do the reference counting. In fact
this is how refcounting is done usually anyway?
Well, when there is no garbage collection involved then yes, that is
how you normally do it but in the GC case, there is the question of
what is the appropriate time to call destructor on garbage collected
data (like jump functions)?
I still fail to see problem here. Summaries are explicitly managed- they are
constructed at summary construction time or when new callgarph node is
introduced/duplicated. They are destroyed when callgarph node is destroyed or
whole summary is ddestroyed. It is job of the summary datastructure to call
proper ctors/dtors, not job of garbage collector that provides the underlying
memory management.
I do not think that all summaries (in the meaning of a description of
one particular symbol table node or call graph edge) are explicitely
managed. For example ipa_edge_args or ipa_agg_replacement_value
(which my alignment patch changes to ipcp_transformation_summary) are
allocated in GC memory because they contain trees.
If you have datastructure that points to something that is not
explicitly managed (i.e. tree expression), you just can not have
non-trivial constructor on that datastructure, because that is freed
transparently by gty that don't do destruction...
I admit to not being particularly bright today but that seems to be
exactly my point.
Well, in your case you have datastructure jump_function that contain a pointer
to tree (EXPR). What I am trying to explain is that I see no reson why
jump_function needs to be POD.
I never said that the summary object needs to be a POD, I only said I
liked the possibility of storing very simple objects (without wrapping
them in classes with constructors and destructors). That is of course
nothing more than my personal preference.
The tree pointed to by EXPR pointer can not
have a dtor by itself because GGC will not call it upon freeing.
It is true that jump_function lives in GGC memory (to make pointer to expr
work) but it never gets removed by ggc_collect because it is always pointed to
by the summary datastructure. There are two ways to free the jump_function
datastructure.
1) removing the symbol node it is attached to.
Here the symtab code will call removal hook that was registered by container
template. The container will call destructor of jump_function and the ggc_free
its memory
2) removing the summary. In this case I would again expect the container
template to walk all summaries and free them.
So even if your structure lives in GGC memory it is not really garbage
collected and thus the lack of machinery to call dtors at a time ggc decides to
free something is not a problem?
In fact looking at struct default_hashmap_traits, I see:
/* Called to dispose of the key and value before marking the entry as
deleted. */
template<typename T> static void remove (T &v) { v.~T (); }
Now I see, I should have read your previous email more carefully, by
explicitely managed you mean that destructors will be called
explicitely by the summary infrastructure. I was wondering how you
wanted to rip the summaries out of GGC memory.
Well, I suppose that would work, and since explicit calls to
destructors are basically the counterpart of placement new that we
already plan to use, it might be actually be the proper C++ thing to
do.
(I am not sure I like it though, for all other purposes the summary
objects will look like managed by the garbage collector and only we
who read this thread will know that the lifetime of the object would
be decoupled from the allocation-span of its memory).
Thanks for the clarification,
Martin