Scott,

> I think that instead of doing a full GC, do an incremental GC
> and tenure the results immediately. Looking over the code,
> this seems to be easy, if its OK to do an incremental GC
> from within:
>
> ObjectMemory>>noteAsRoot:headerLoc:
>
> Is it?

It is not. Look at the senders - one of them is
#possibleRootStoreInto:value: which is called by
#storePointer:ofObject:withValue: The latter is *THE* crucial method for
storing any object in Squeak. Making all its senders GC-safe (which
includes, amongst others, the byte codes for storing a receiver variable)
costs you a *lot* more than you could possibly gain. I have almost never
seen a root table overflow (except when I was running some massively
parallel stuff with some 10000 processes ;-))) and it's just not worth the
effort.

If you *really* want to decrease the overhead, then you should do the
following: Reserve some extra slots for the possibility of a root table
overflow (say 100). If you reach the red zone, set the allocationCount to be
larger than allocationBetweenGCs. This will trigger an incrementalGC at the
very next allocation (and you can then tenure based on being in the red zone
of the root table). If you want to go even further you could zap the
recycled contexts which means that you don't even need an explicit
allocation - the next real send will trigger an IGC.

Of course, there's still a chance that you get a root table overflow plus
full GC in a tight loop but that seems to be *extremely* unlikely.

Cheers,
  - Andreas