On Wed, Jan 12, 2011 at 1:37 AM, Josh Gargus <josh@schwa.ca> wrote:


On Jan 11, 2011, at 11:48 PM, Igor Stasenko wrote:

>
> Eliot, one thing about 'forwarded' objects, which you calling the
> forwarding corpse is that it can be used not only for pinning,
> but also with #becomeForward primitive, making it work a lot faster,
> since its not require to scan whole heap to update references,
> and update can be done during GC.
> The only problem, as you pointed out, is the objects which don't have
> enough space for forwarding pointer. But for this case, i think the
> primitive can fall back and use old slow scheme.

I was thinking the same thing.  But wouldn't there remain the problem that Eliot mentioned about objects with named variables?

You're both right.  The issue of objects with named inst vars is important (see my reply to Steve's post; performance is one issue).  One wants to do lazy become, but without imposing checking costs on operations with high dynamic frequency.  That's what's so beautiful about changing the class; it piggy-backs on the inline cache check, and moves the actual check and fix-up to a rare and expensive path, that of an inline cache miss, without imposing any extra costs on the common case of a send to a non-corpse object.  The implementtion challenge is to come up with a scheme for objects with named inst vars that doesn't add large costs to inst var access.

Since the current Cog become has to scan activations in the stack zone anyway, using corpses and scanning the stack zone (basically eagerly becomming activations in the stack zone) is already cheaper than the current become, whose only significant optimization is to scan only the remembered table the stack zone and new space if all objects being becommed are young.


Thanks for this discussion.  This is making increasing sense.  So lazy become and corpses will be used for all non-zero-sized objects.  Cool.

best
Eliot

Cheers,
Josh