Re: [RFC] two-phase marking in gt_cleare_cache

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 6 Jul 2015, Richard Biener wrote:

> >> By doing so, we make the behaviour of gt_cleare_cache independent of the
> >> order in which the entries are visited, turning:
> >> - hard-to-trigger bugs which trigger for one visiting order but not for
> >>   another, into
> >> - more easily triggered bugs which trigger for any visiting order.
> >>
> >> Any comments?
> >
> > I think it is only half-way correct in your proposed change.  You only
> > fix the issue for hashes of the same kind.  To truly fix the issue you'd
> > have to change generated code for gt_clear_caches () and provide
> > a clearing-only implementation (or pass a operation mode bool to
> > the core worker in hash-table.h).
> 
> Hmm, and don't we rather want to first mark and _then_ clear?  Because 
> if entry B in the hash is live and would keep A live then A _is_ kept in 
> the end but you'll remove it from the hash, possibly no longer using a 
> still live copy.

I don't think such use has ever worked with the caching hash tables.  Even 
the old (before c++) scheme didn't iterate, i.e. if a cache-hash entry A
became life from outside, but it itself kept an entry B live in the hash 
table (with no other references to B) then this never worked (or only by 
luck), because the slot was always cleared if !ggc_marked_p, so if B was 
visited before A it was removed from the hash-table (and in particular B's 
gt_ggc_mx routine was never called, so whatever B needed wasn't even 
marked).

Given this I think the call to gt_ggc_mx is superfluous because it 
wouldn't work relyably for multi-step dependencies anyway.  Hence a 
situation that works with that call in place, and breaking without it is 
actually a bug waiting to be uncovered.


Ciao,
Michael.