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. The tree pointed to by EXPR pointer can not
> have a dtor by itself because GGC will not call it upon freeing.
ggc does call dtors when it is about to sweep an object. however if you
explicitly call ggc_free on an object with a dtor you need to call the
dtor manually I believe.
> 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.
assuming it doesn't need to go into pch, and I would really think it
never does there's no real reason it has to live on the heap, you could
iterate over all the summaries and mark all the trees they point at
"manually".
> 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.
actually I think it should be, ggc tracks when objects with non trivial
dtors are allocated and sets up finalizers for them to run the dtor.
Trev
> 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
