[Webkit-unassigned] [Bug 148610] New: JSC should infer property types

[bugzilla-daemon at webkit.org]

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

            Bug ID: 148610
           Summary: JSC should infer property types
    Classification: Unclassified
           Product: WebKit
           Version: Other
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

Here's the basic design:

- PropertyMapEntry tells you if a property is subject to type inference.  If it is, then before storing into it, you need to look up the property's offset in the Structure's type inference table.  If the value being stored is a member of the type according to that table, you can store.  Otherwise, you need to do something to broaden the type.

- The Structure's type inference table maps offsets to InferredType objects.  InferredType objects are GC cells.

- When a Structure transition occurs, the new structure's type inference table will share the same InferredType objects as the old structure for all of the properties that the two structures have in common.  This ensures that if a store occurs on the old structure that causes a change in the inferred type, then users of the new structure immediately find out that they may now see that new type.  Note that this is slightly conservative: it also means that if the type changes on the new structure, the old structure will find out, even though it doesn't need to.

- All stores from a reflective context (i.e. not PutById) immediately disable type inference on the property by causing the InferredType to become TOP.

- Dictionary transitions disable type inference by simply not copying the type inference table.  This means that it doesn't affect the type inference of prior structures. It does mean that both the dictionary structure and all of its successors (including when it's flattened) will not enjoy type inference.  The upside is that dictionary puts - which are expensive to begin with - don't have to validate types.  We're assuming that once a dictionary transition happens then it's because many accesses will be reflective.  Another common use of dictionaries is for prototypes, which will often be dictionaries until they are flattened.  But prototype accesses usually benefit from immutable property inference already, so it's OK if type inference sometimes fails.

- Property type will not, at least initially, have any effect on property representation.  It just guarantees that you don't have to do some type check after load.

- Property type will include Structure, for those Structures that have a valid transition watchpoint.  InferredType will register a watchpoint on the transition, and will generalize to "Object" if the watchpoint fires.  That way, we don't have to worry about some object having the structure at the time we store a reference into a property, but then the object's structure changes.  We'll only do the inference if the transition had never fired, and when it does, the property finds out.

- All put_by_id inline caches will have to do type checks, except of course when we already have a proof about what the type is.  Such a proof will probably only happen in the DFG/FTL.

-- 
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/20150829/6a7de6c6/attachment.html>