Closed Bug 557963 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dmandelin, Assigned: dmandelin)

References

Details

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.
Depends on: 557969
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
No longer depends on: 557969
Depends on: 557969
Depends on: 561238
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.
Assignee: general → dmandelin
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.