> 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. 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 (); }
This trait gets called by the underlying hash table so if you have explicitly
managed hashmap (in GGC memory or not), things just work. Only catch is that
if you let your hashmap to be garbage collected, then your dtor is not called.
So probably the dtors are working same way with Martin's summaries?
I guess we can follow same scheme here, have summary_traits that default
to calling correspondin ctors/dtors.
Honza
>
> Martin
