[webkit-dev] Making more use of ScriptWrappable

[Adam Barth]

To update this thread: I've now got this working in the V8 bindings.
The next step is to make this work in the JSC bindings.  If you're
interested in the details, the work will occur on
<https://bugs.webkit.org/show_bug.cgi?id=101279>.

On Thu, Nov 1, 2012 at 10:51 AM, Alexey Proskuryakov <ap at apple.com> wrote:
> Do you have a rough estimate of how large of a win we are talking about?

As a simple example, adding ScriptWrappable as a base class for
DOMImplementation makes document.implementation 23% faster, at least
as measured with the V8 bindings (see
<https://bug-101279-attachments.webkit.org/attachment.cgi?id=172440>).

Although I doubt that document.implementation itself is a performance
bottleneck, using ScriptWrappable more widely seems likely to improve
both performance and memory usage.

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):

A) It's always faster to get and set the JavaScript wrapper with
ScriptWrappable.
B) In terms of memory, we pay 1*sizeof(void*) for every instance with
ScriptWrappable compared to 2*sizeof(void*) for every instance that
has a JavaScript wrapper in the non-ScriptWrappable case (discounting
the fact that Hashtable actually seems to keep a constant fraction of
its buckets free).

> (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.

Turns out we don't need the IDL attribute (see the next question).

> (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.

Thanks,
Adam


On Thu, Nov 1, 2012 at 10:36 AM, Adam Barth <abarth at webkit.org> wrote:
> We currently use two different approaches for associating JavaScript
> 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
> translate the object into a JavaScript wrapper.
>
> Whether to use ScriptWrappable or a HashMap is a trade-off that
> depends on the workload.  For DOM objects that rarely have a
> JavaScript wrapper, using a HashMap is more memory efficient because
> 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
> JavaScript wrapper, using ScriptWrappable is both faster (because we
> 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
> almost always have JavaScript wrappers.  For example, XMLHttpRequest
> objects exist only when created by script, which means that every
> XMLHttpRequest object has a JavaScript wrapper.
>
> 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
> performance.
>
> Please let me know if you have any feedback.
>
> Thanks!
> Adam