Bootstrap failure due to GC / PCH memory corruption

[Geoff Keating]

> X-Original-To: geoffk@foam.wonderslug.com
> Cc: gcc@gcc.gnu.org
> From: Zack Weinberg <zack@codesourcery.com>
> Date: Fri, 27 Jun 2003 09:33:03 -0700

> Geoff Keating <geoffk@geoffk.org> writes:
> 
> >> I also suggest that you find out what these objects are that are
> >> larger than a page.  To first order there shouldn't be any.  The only
> >> thing I've ever seen allocate more than a page at once from GC arena
> >> was a giant dense switch statement.
> >
> > There are many such objects, for instance the identifier hash table is
> > a minimum 200k.
> 
> Since when is the identifier hash table allocated with ggc_alloc?
> ht_create uses xmalloc.

Hmmm.  I forgot that the string pool is treated specially.  If PCH is
in use, gt_pch_save_stringpool will create a GCed object from the
string pool, but I guess that's kind of a special case.

Well, consider type_hash_table in tree.c.  It starts off slightly
smaller than a page (4004 bytes, I think) but if you have more than
600 or so types in your program it'll expand to be multiple pages.

If a routine has more than 1024 psuedos, then x_regno_reg_rtx in
struct emit_status will be more than a page.  I've seen real routines
(after inlining) with more than 200,000 pseudos.  There are other
arrays that are some function of the number of registers or the number
of basic blocks.

> I should point out that ggc-page.c is heinously inefficient when
> allocating objects larger than a single page.  This is tolerable
> as long as we don't allocate very many such objects, but if we are
> now allocating lots of them, it needs to be fixed.

There wouldn't usually be a large number of them (after all, each one
of them takes at least two pages) but any efficiency gains would be
helpful.

-- 
- Geoffrey Keating <geoffk@geoffk.org>