ggaren at apple.com
Mon Jul 13 13:31:42 PDT 2009
> Our current thinking is to add a parameter to toJS() to receive the
> JSGlobalObject in which to create the wrapper.
> Once we do that, the question is how to find the proper
> JSGlobalObject at each call site.
> In most cases, you have another JSObject sitting around that is from
> the right JSGlobalObject. In the document.body example, the getter
> for body has the JSDocument from which it gets the body property. We
> can then use Heap::heap(sittingAroundObject)->globalData() to get back
> to the right JSGlobalObject.
Heap::heap() will give you a JSGlobalData pointer, but not a
JSGlobalObject pointer. All JSGlobalObjects in WebCore share the same
Heap and the same JSGlobalData.
Using a different heap for each JSGlobalObject would be a pretty major
> An alternative is to add state to every JSDOMObject to remember with
> which JSGlobalObject it's associated. This might have memory
Almost all DOM access proceeds from [ window ] -> [ document ] ->
[ interior stuff ], so it's probably feasible to propagate a window
pointer along all chains of property access. This would also be a
pretty major change, though.
originated execution, and the global object in which the currently
executing function was defined. So, if script S calls function F, it's
trivial to figure out the window in which S was loaded, and also the
window in which F was defined. But figuring out the window from which
an arbitrary object originated seems challenging.
More information about the webkit-dev