[webkit-dev] Making more use of ScriptWrappable

Maciej Stachowiak mjs at apple.com
Tue Nov 6 22:17:43 PST 2012

On Nov 5, 2012, at 5:07 PM, Adam Barth <abarth at webkit.org> wrote:

> On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> Sounds like a good idea. Three additional thoughts:
>> (1) It would be best to choose the objects to apply this to in some data-driven way.
> Do you have a suggestion for what data to use?  As far as I can tell,
> adding ScriptWrappable as a base class is a win whenever at least half
> of the instances of the object have JavaScript wrappers (in the main
> world):

It's clearly an all-round win for speed and memory when this condition is true. I imagined some straightforward instrumentation to find classes where this condition is true (or nearly true) on some representative set of websites. Applying ScriptWrappable to these classes is definitely pure win.

When the condition is not true (wrapper exists in main world significantly less than half the time), it's a size-speed tradeoff. It may be worth it in cases if the memory cost is low and the speed gain is high (for example, one object per document, but its wrapper is accessed often). That may require some judgment calls.

>> (3) I suspect that we can handle this without adding an IDL attribute at all. C++ overloaded functions could let the bindings do something different for objects that inherit ScriptWrappable from ones that do not in a generic way, without having to explicitly tell the bindings layer about the ways to do it. Consider the ways unwrap() and toJS() are done. We don't have to say anything special in the IDL or have any interface-specific knowledge in the bindings, C++ overloading takes care of it.
> Thanks for the suggestion.  I got this work (at least for the V8
> bindings---JSC is next on my list).  To make something
> ScriptWrappable, you just need to add ScriptWrappable as a base class:
> -class DOMImplementation {
> +class DOMImplementation : public ScriptWrappable {
> I'm not super excited about the name given that all DOM objects are
> wrappable by script.  If folks have thoughts about a better name, I'd
> appreciate suggestions.

I agree with you that the name could use improvement. The only suggestion I can think of that is not ridiculously verbose would be InlineWrappable, but I am not sure if that is more clear overall.


More information about the webkit-dev mailing list