A recent patch increased GCC's memory consumption!

[Jan Hubicka]

> 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.

Honza
> 
> But as said -- another time.
> 
> Richard.