[Webkit-unassigned] [Bug 95073] WindowShell and global registers break IC

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95073





--- Comment #7 from Filip Pizlo <fpizlo at apple.com>  2012-08-27 21:03:47 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > Our typical defense against this type of bug is that the function doing the lookup and caching checks that the property owner (PropertySlot::slotBase()) is equal to the object on which it's doing the lookup, and refuses to cache if not. 
> > 
> > Do you know what goes wrong with that defense in this case?
> 
> Yes. forceUncacheable is necessary for browser environment, not JSC shell.
> 
> In the shell, global object is JSGlobalObject, but in the browser, global object is JSDOMWindowShell object(this is proxy to JSGlobalObject)
> WindowShell object has JSGlobalObject and lookup operations are passed to JSGlobalObject. But this makes a severe problem.
> https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSDOMWindowShell.h#L80
> 
> For example, we define own property to global and lookup.
> window.a = 20;
> window.a;
> 
> When lookup is executed, WindowShell lookups from JSGlobalObject.
> https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSDOMWindowShell.cpp#L94
> 
> As the result, when lookup is succceeded, slot.baseValue() is JSGlobalObject (not WindowShell).
> But, `window` object(baseCell) is WindowShell. So currently JSC on Safari has already failed at self IC creation point.
> https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/jit/JITStubs.cpp#L932

I think this last paragraph explains why you don't need forceUncacheable().  Why do you need to force uncacheable when JSC already chooses not to perform caching since baseValue is not the same as slotBase?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.