Ephemeral garbage [Was: GCC 3.2.1 -> GCC 3.3 compile speed regression]
Mike Stump
mstump@apple.com
Mon Feb 3 20:42:00 GMT 2003
On Saturday, February 1, 2003, at 12:09 AM, Timothy J. Wood wrote:
> Another possibility that occurs to me is that 3.3 might be
> allocating more ephemeral blocks. I guess you could say that this is
> better temporal locality, but maybe its just a few sloppy temporary
> object allocations.
I have a suggestion for this case. ggc_free. ggc_free would be
documented as:
ggc_free
Routine to be called on an object allocated by ggc_alloc when the
object is known to not have any other references that are live left.
Semantics, when ENABLE_CHECKING is off, the object is immediately made
available for reallocation via ggc_alloc, without any fuirther
checking. This routine can be used to speed GC in common cases like:
while (++try < MAX_TRIES)
{
o = ggc_alloc ();
if (property (o) < min)
{
min = property (o);
r = o;
}
}
return r;
and after:
while (++try <MAX_TRIES)
{
o = ggc_alloc ();
if (property (o) < min)
{
min = property (o);
r = o;
} else {
ggc_free (o);
}
}
return r;
With ENABLE_CHECKING, we could mark them as should be free until the
next collect, and at collect time, we can double check that the object
is indeed unreferenced, and then truly free it, otherwise, abort.
Thus, we get the speed tight alloc/dealloc code for releases, with the
error checking of full GC during development for objects that we
actually know something about. This should give us the advantages of
both worlds, with the flexibility of either world, depending upon needs.
More information about the Gcc
mailing list