Bug 117385 – fourthTier: DFG should support op_in and it should use patching to make it fast

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

Patch forthcoming.

[Filip Pizlo]

Created attachment 204122 [details]
very early work in progress

Still figuring out what the best way of doing this is.

[Filip Pizlo]

Created attachment 204277 [details]
it should just work

[Filip Pizlo]

Created attachment 204289 [details]
it did just work

Still need to implement 32-bit part, still need to run more tests.

[Filip Pizlo]

Still debugging some LayoutTests/jquery crashes.  No perf numbers yet other than microbenchmarks which speed up by a *lot*.

[Filip Pizlo]

Created attachment 204361 [details]
the patch

[Filip Pizlo]

Created attachment 204375 [details]
the patch

32-bit now builds and runs clean.

[Filip Pizlo]

Created attachment 204376 [details]
the patch

Added JSRegress tests.

[Filip Pizlo]

This isn't a small speed-up.


   in-four-cases                                 297.3037+-2.8573     ^     21.8263+-0.1147        ^ definitely 13.6213x faster
   in-one-case-false                             178.0126+-2.6962     ^     10.4301+-0.1371        ^ definitely 17.0673x faster
   in-one-case-true                              156.9623+-2.0516     ^     10.1108+-0.0654        ^ definitely 15.5242x faster
   in-two-cases                                  166.7664+-1.6888     ^     10.5953+-0.1015        ^ definitely 15.7397x faster

[Geoffrey Garen]

Comment on attachment 204376 [details]
the patch

Would be nice to take even more advantage and further optimize for cases like

    if (!("property" in object))
        throw "oops!";
    return object.property;

but I can't in good conscience thumb my nose at a 17X speedup.

[Filip Pizlo]

(In reply to comment #9)
> (From update of attachment 204376 [details])
> Would be nice to take even more advantage and further optimize for cases like
> 
>     if (!("property" in object))
>         throw "oops!";
>     return object.property;

Yes.  Here's the plan:

1) Get the baseline JIT to use the DFG's inline caching logic, including for op_in.

2) Have the DFGByteCodeParser extract the inline cache data for op_in the same way it does for op_get_by_id and friends.

3a) For In's that only have one case in the inline cache and they didn't take slow path, simply turn them into CheckStructure and their result becomes a JSConstant(true) or JSConstant(false).

3b) For In's that too two cases (a true and a false case), integrate Branch(In(@object)) with the CFA such that the CFA will remember that on the then case of the Branch, we know that @object has the true structure, and on the else case of the Branch, we know that @object has the false structure.  We haven't yet done such things in the CFA, but they are easy to do in our IR; they'll just require a slight refiddling of the relationship between the CFA's executeEffects() method and the mergeXYZ() methods; executeEffects() will have to convey to the merge methods that we will want to merge slightly different data for the different paths of the branch.

> 
> but I can't in good conscience thumb my nose at a 17X speedup.

Seems sensible! ;-)

OTOH, this didn't really speed up pdfjs despite increasing coverage, and despite the fact that pdfjs is clearly making good use of the inline caching - disassembly dumps show lots of juicy DFG In stubs, and most of them look optimal.  So I guess those functions that used 'in' simply weren't on the hot path.  Oh well it happens.  Still happy that I made it fast.

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/151569