Re: question about if_marked construct

[Tom de Vries <tjvries at xs4all dot nl>]

On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:

> Basile Starynkevitch <basile@starynkevitch.net> writes:
>
> > On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
> > > Tom de Vries <tjvries@xs4all.nl> writes:
> > >
> > > > What I am really trying to do, is a bootstrap debug build of 4.3.5.
> > > > However, I ran into bug 31230. I minimized the testcase, did an
> > > > analysis, created a naive patch to test my hypothesis, tested the
> > > > patch and put it in the bug report. Now I'm looking for feedback.
> > > >
> > > > In the question I asked to this mailing list I tried to abstract  
> > > > away
> > > > > From the specific case I analyzed, to get a more conceptual
> > > > discussion about the garbage collector, but maybe that was a  
> > > > mistake,
> > > > sorry for the confusion.
> > > >
> > > > My analysis, what I'm trying to get confirmed, is that the the  
> > > > actual
> > > > type_hash_marked_p() in gcc is 'such an if_marked property':
> > > > ...
> > > > static int type_hash_marked_p (const void *p) {
> > > >  tree type = ((struct type_hash *) p)->type;
> > > >  return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
> > > > }
> > >
> > > Interesting.  My first reaction is that this is an invalid use of  
> > > the
> > > garbage collector.  I think there is really only one valid function
> > > that can be used as an if_marked function: one which checks
> > > ggc_marked_p on the structure.
> >
> >
> > A plugin providing its own GC above GGC, like MELT does, also  
> > could use
> > that feature. So don't remove it, please.
>
> I'm not proposing removing any feature.  I'm stating my belief that
> using if_marked with a function which does anything other than test
> ggc_marked_p will not work.  I don't think it works today, and I don't
> think we should put effort into making it work.
>
> Ian

Going from your assessment that the current implementation of  
type_hash_marked_p() is incorrect, I think that for 4.4, 4.5 and  
trunk it's enough just to remove the TYPE_SYMTAB_POINTER from the  
clause (-funit-at-a-time is hardcoded and makes sure the types  
between functions stay alive). Fixing this by building a separate  
garbage collection root as you suggest would only be needed for 4.3  
and earlier.
However, my feeling is that the problem does not classify as a  
regression, so I suppose we'd only fix it for the trunk anyway. I'll  
try to test a patch for the trunk.

Tom