[webkit-dev] Making more use of ScriptWrappable
mjs at apple.com
Thu Nov 1 16:10:12 PDT 2012
On Nov 1, 2012, at 6:36 PM, Adam Barth <abarth at webkit.org> wrote:
> wrappers with DOM objects. For some objects, we store the wrapper
> inline in the object itself by making object inherit from
> ScriptWrappable. For other types of objects, we use a HashMap to
> Whether to use ScriptWrappable or a HashMap is a trade-off that
> depends on the workload. For DOM objects that rarely have a
> we don't need to store a large number of null pointers in objects that
> do not have wrappers. By contrast, if an object almost always has a
> avoid the hash table lookup) and uses less memory (because we don't
> need to store both the key and the value in the HashMap---we just need
> to store the value in the object itself).
> Today, we use ScriptWrappable for Nodes only, but we would benefit by
> making more use of ScriptWrappable, particularly for DOM objects that
> objects exist only when created by script, which means that every
> My plan is to introduce an interface-level IDL attribute named
> something like [OftenHasJSWrapper] that informs the code generator
> that the object inherits from ScriptWrappable and that we should make
> use of the inline wrapper. We can then deploy this attribute as
> appropriate throughout WebCore to reduce memory usage and improve
> Please let me know if you have any feedback.
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.
(2) If we have an IDL attribute, I think it should be named by the effect it has, not the possible conceptual-level reason for applying it. [ScriptWrappable] or [InlineWrapper] or something. Because it's not a judgment call, it is a statement about the code.
(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.
More information about the webkit-dev