Just had a "doh!" moment with literal variable unforwarding...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Just had a "doh!" moment with literal variable unforwarding...

Eliot Miranda-2
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Just had a "doh!" moment with literal variable unforwarding...

Clément Béra
 
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 <[hidden email]> 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