[Webkit-unassigned] [Bug 157324] New: References from code to Structures should be stronger than weak

[bugzilla-daemon at webkit.org]

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

            Bug ID: 157324
           Summary: References from code to Structures should be stronger
                    than weak
    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 code refers to a Structure and the Structure dies, then currently we'll kill the code.  This makes sense because the Structure could be the only thing left referring to some global object or prototype.

But this also causes unnecessary churn.  Sometimes there will be a structure that we just haven't really done anything with recently and so it appears dead.  The approach we use elsewhere in our type inference is that the type that the code uses is general enough to handle every past execution.  Having the GC clear code when some Structure it uses dies means that we forget that the code used that Structure.  We'll either assume that the code is more monomorphic than it really is (because after GC we patch in some other structure but not the deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's crazier than it really is (because we'll remember that there had been some structure that caused deletion, so we'll assume that deletions might happen in the future, so we'll use a fully dynamic IC).

We should have a more nuanced policy: if it's cheap to mark a dead Structure then we should mark it just so that all of the code that refers to it remembers that there had been this exact Structure in the past.  If the code often goes through different Structures then we already have great mechanisms to realize that the code is nutty (namely, the PolymorphicAccess size limit).  But if the code just does this a handful of times then remembering this old Structure is probably net good:

- It obeys the "handle all past executions" law.
- It preserves the history of the property access, allowing a precise measure of its past polymorphism.
- It makes the code ready to run fast if the user decides to use that Structure again. Marking the Structure means it will stay in whatever property transition tables it was in, so if the program does the same thing it did in the past, it will get this old Structure.

Right now it looks like this is a progression in gbemu and it makes gbemu perform more deterministically. I still need to do more experiments to validate this.

-- 
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/20160503/7b95be87/attachment.html>