557963 - JM: make sure the cached prototype is for the same global object

Status: RESOLVED FIXED

Description

[David Mandelin [:dmandelin]]

PICs can generate a stub to access string methods (from primitive strings). The current implementation simply bakes in the address (since it is guaranteed to have been cached by the time the PIC runs), like TM.

But this isn't quite right--it needs to verify that the global object for the PIC-cached string method is the same as the global object for the current method. If anyone has any suggestions for doing this cheaply, let me know. Otherwise, I'm thinking that eventually we should store the global object directly inside functions, which would make this comparison simple.

Comment 1

[Brendan Eich [:brendan]]

We do store the global object in functions, via __parent__. Oops, my patch to avoid sticking String.prototype in String.prototype.split.__parent__ didn't land, but you can still find the global by going up twice:

js> String.prototype.__parent__ == this
true
js> String.prototype.split.__parent__ == this
false
js> String.prototype.split.__parent__ == String
false
js> String.prototype.split.__parent__ == String.prototype
true
js> String.prototype.split.__parent__.__parent__ == this  
true

I filed bug 557969 on native method parent slot linking directly to global.

/be

Comment 2

[David Mandelin [:dmandelin]]

Now that I know that COMPILE_N_GO means we are safe, I just set it up to deoptimize (back to the prop cache, so not bad, really) string method lookups if not in COMPILE_N_GO mode.