[Webkit-unassigned] [Bug 156391] New: Accesses that are polymorphic on base but all share the same slot base in some shared prototype should use a hash set of structures for resolution

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 7 21:09:35 PDT 2016


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

            Bug ID: 156391
           Summary: Accesses that are polymorphic on base but all share
                    the same slot base in some shared prototype should use
                    a hash set of structures for resolution
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

If we want to cache accesses to some prototype that doesn't need repatching when new base structures come along, then we would emit this code:

- Materialize a pointer to the prototype's hashtable for this property.
- Mask or shift the structure ID to produce a hash code (on 64 bit: mask since it's a densely allocated integer ID; on 32-bit: downshift since it's a pointer)
- Load a structure ID from the hashtable.
- Check if it's the one we wanted.  (Common case is that we stop here.)
- Bail if it's the deleted value sentinel.
- Increment and loop if it's not the empty value sentinel.
- If we find the structure ID in the hashtable, we produce the result value (either produce the constant or load from the prototype).

The fast path will thus involve one load-and-branch, plus some minor integer computation.

The way this will work is that it will be backed by a hashtable hanging off the prototype's property.  Anytime we try to cache an access to that property by way of a prototype chain, we check if the prototype chain is watchable.  If it is, we watch it and put the base structure into the hashtable.

Note that the code we generate inlines a pointer to the hashtable and the mask amount.  Thus, if we rehash, we trigger watchpoints on those StructureStubInfo's so that they can be regenerated.  Alternatively, we would let them regenerate if they ended up taking slow path.

-- 
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/20160408/8ad54530/attachment.html>


More information about the webkit-unassigned mailing list