[Webkit-unassigned] [Bug 163226] New: [JSC][DOMJIT] IC should have a way to handle super-polymorphic DOM accessor calls

[bugzilla-daemon at webkit.org]

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

            Bug ID: 163226
           Summary: [JSC][DOMJIT] IC should have a way to handle
                    super-polymorphic DOM accessor calls
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: utatane.tea at gmail.com

This inlining is super effective if we run some microbenchmarks. However, Dromaeo does not
show so much performance benefit. This is because Dromaeo's dom-traverse.html is super
polymorphic call site where JSC gives up optimization. For example, in the following
dromaeo's benchmark, we can see so various DOM nodes at the `cur.firstChild` site, like,
HTMLDivElement, HTMLAnchorElement, Text, Comment etc. JSC gives up optimization since we
encounter so many Structures. This should be optimized since they share the large part of
prototype-chain and they hit the exactly same CustomGetter, Node.prototype.firstChild.

               test( "firstChild", function(){
                   var nodes = document.body.childNodes, nl = nodes.length;

                   for ( var i = 0; i < num; i++ ) {
                       for ( var j = 0; j < nl; j++ ) {
                           var cur = nodes[j];
                           while ( cur )
                               cur = cur.firstChild;
                           ret = cur;
                       }
                   }
               });

This is unfortunate because this call site has very interesting features.

1. All the look up hits the exact same accessor of the same object (Node.prototype).

This call site hits the same Node.prototype.firstChild custom accessor. Inlining has a chance to optimize it.

2. Structure chain of polymorphic ones are very very similar.

While we see various Structures at this call site, their ancestors are quite similar.

HTMLDivElement -> HTMLDivElement.prototype -> HTMLElement.prototype -> Element.prototype -> Node.prototype -> ...
HTMLAnchorElement -> HTMLAnchorElement.prototype -> HTMLElement.prototype -> Element.prototype -> Node.prototype -> ...
Text -> Text.prototype -> CharacterData.prototype -> Node.prototype -> ...

We can ensure that Node.prototype, Element.prototype, and HTMLElement.prototype are not changed by using watchpoint. And typically they are not changed so frequently.
Caching Structures of HTMLDivElement, HTMLAnchorElement, and Text is the current design. But it does not work because there are so many structures.

So, what we should do is ensuring non watched Structures (e.g. HTMLDivElement -> HTMLDivElement.prototype) does not have the property with the specific name ("firstChild").

After discussing with rniwa and keith_miller, currently, I'm planning to add a bloom filter for each Structure.
This filter says "This Structure must not have a property with the specific name".
And by using this, we can query the given Structure chain does not have a property with the specific name ("firstChild").

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161010/665cfe74/attachment.html>