This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
random thought re GC allocator
- To: gcc at gcc dot gnu dot org
- Subject: random thought re GC allocator
- From: "Zack Weinberg" <zackw at stanford dot edu>
- Date: Sun, 27 May 2001 11:52:06 -0700
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_