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

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: dmandelin, Assigned: dmandelin)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

9 years ago
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
(Assignee)

Updated

9 years ago
Depends on: 561238
(Assignee)

Comment 2

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.