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)
Core
JavaScript Engine
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.
Comment 1•15 years ago
|
||
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
Assignee | ||
Comment 2•15 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
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•