[Vm-dev] Just had a "doh!" moment with literal variable unforwarding...

Clément Bera bera.clement at gmail.com
Mon Dec 5 17:26:24 UTC 2016


Hi,

Why not. Associations referred from machine code are kept in a list to be
updated as post-become action. We never keep the association live in
register or anywhere so it should work.

Now I am thinking maybe we should scan all the machine code zone as a post
become action to update literals so when #== happens we don't need to check
for forwarders for annotable constant operand. In "var1 == 'string'", we
would know 'string' is not a forwarder. And for super sends to annotable
constant too.

Although all of this is about uncommon cases so I don't know if it really
matters...

On Mon, Dec 5, 2016 at 5:51 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Clément,
>
> I just realized that if we maintain a list of machine code methods that
> reference global variables, in a similar fashion to the list of methods
> that refer to new literals, then we can scan the list post-become and
> ensure that all are unforwarded. hence the code generator can avoid
> generating the unforwarding code on access.
>
> We could probably use the same list for both methods with global
> references and methods with new references. Since a method is marked as
> referring to new objects (cmRefersToYoung) we can avoid scanning methods
> that simply refer to globals when we scavenge.  That we have to visit a few
> extra methods after become (the cmRefersToYoung methods that don't refer to
> globals) is unlikely to be a hardship; there are very few methods on the
> youngReferrers list.
>
> What do you think?
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161205/4719cbcf/attachment.html>


More information about the Vm-dev mailing list