Re: A recent patch increased GCC's memory consumption!

[Richard Guenther <rguenther at suse dot de>]

On Thu, 28 Feb 2008, Jan Hubicka wrote:

> > On Thu, 28 Feb 2008, Jan Hubicka wrote:
> > 
> > > > On Thu, 28 Feb 2008, Jan Hubicka wrote:
> > > > 
> > > > > > On Thu, 28 Feb 2008, Jan Hubicka wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > > memory tester didn't run for a while but I do believe this memory usage
> > > > > > > growth is yours.  Looks like is_marked_p hack does not work somehow?
> > > > > > 
> > > > > > It should..., but as the patch seems to cause bootstrap failure on i686
> > > > > > I am going to revert it again anyway.  I have no time investigating all
> > > > > > this mess.
> > > > > 
> > > > > It would be shame to give it up completely.  Is the i686 breakage also
> > > > > ggc_free related?  I can try to help here.
> > > > > Reverting will definitly tell us if the memory usage goes back however.
> > > > 
> > > > No idea, it is a bootstrap comparison failure, so I'd guess a GC 
> > > > dependency during referenced vars walk.
> > > 
> > > I see.  Clearly with with the is_marked_p we have dependency here, since
> > > removing stuff from hashtable triggers different resizing that triggers
> > > different ordering.  Can't we live without the walk?
> > 
> > Nono, we made refernced vars a bitmap, so it is _not_ dependent on
> > GC, but is strictly UID ordered with the patch.  We don't walk the global
> > table.  But what can happen is that the strictly odered UID walk comes
> > along a dead DECL and thus the amount of decls visited is dependend on
> > GC (not their order).  But of course the decl would be dead anyway, with
> > or without GC -- so scheduling remove_unused_vars properly or not doing
> > things dependent on dead decls would fix this.
> 
> If you do maintain references to the hashtable using bitmap UIDs, how do
> you deal with the declarations disappearing from the table in GGC?
> It seems to me that either GGC would need to understand that the bits in
> bitmaps are de-facto pointers to hashtable or we would have to
> remove_unused_vars in all functions after each GGC to be safe to not
> point to deallocated buckets.

The new walkers for referenced_vars simply skip over GGCed DECLs.

Richard.