[Vm-dev] pinning GC

Eliot Miranda eliot.miranda at gmail.com
Wed Jan 12 17:44:05 UTC 2011


On Wed, Jan 12, 2011 at 1:37 AM, Josh Gargus <josh at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110112/fafd993f/attachment.htm


More information about the Vm-dev mailing list