Re: Ephemeral garbage [Was: GCC 3.2.1 -> GCC 3.3 compile speed regression]

[Mike Stump <mstump at apple dot com>]

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.