random thought re GC allocator

[Zack Weinberg]

The smallest bin for ggc_alloc is four bytes.  As far as I can tell,
the only objects that small we ever create (modulo a bug in m32r.c,
which allocates a string with ggc_alloc instead of ggc_alloc_string)
are RTXes with zero fields.  There are three such: CC0, PC, and
RETURN.  CC0 and PC are unique.  RETURN is not, but is needed only
rarely and could be made unique (it *appears* that no one ever messes
with the flags or mode of RETURN).

Since CC0 and PC are created in every compilation, the 4-byte bin will
always have at one page, but that page will remain mostly empty.  If
we bump the smallest bin up to 8 bytes, we waste 4 bytes each for CC0,
PC, and every RETURN rtx, but we save most of a page + its control
structure by not having an almost-entirely-empty bin anymore.  There
are lots of 8-byte objects (RTXes with one field, e.g.)

What do people think of this change?

p.s.- This didn't used to be true, because strings (which can be very
short) were allocated from the GC pool too.  Now strings have an
obstack all to themselves.

-- 
zw            I now propose to do a little a priorizing of my own.
              	-- Jerry Fodor, _The Mind Doesn't Work That Way_