Last Comment Bug 612204 - TypeInference: nop CALLPROP fetching known values
: TypeInference: nop CALLPROP fetching known values
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 1 vote (vote)
: ---
Assigned To: general
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks: 619423 638794
  Show dependency treegraph
 
Reported: 2010-11-14 19:31 PST by Brian Hackett (:bhackett)
Modified: 2011-04-13 11:05 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Brian Hackett (:bhackett) 2010-11-14 19:31:23 PST
Most CALLPROPs are accessing a property from a singleton object, either a prototype or a global variable (e.g. Math).  If inference can identify that a CALLPROP is definitely accessing a particular JSObject, and that JSObject always has a particular JSFunction in one of its properties (either from Foo.prototype.f = function () { ... } in global code or from a builtin like x.charCodeAt), the CALLPROP can be nopped and the pushed value statically resolved to that JSFunction.
Comment 1 Brendan Eich [:brendan] 2011-03-05 15:57:40 PST
(In reply to comment #0)
> Most CALLPROPs are accessing a property from a singleton object, either a
> prototype or a global variable (e.g. Math).  If inference can identify that a
> CALLPROP is definitely accessing a particular JSObject, and that JSObject
> always has a particular JSFunction in one of its properties (either from
> Foo.prototype.f = function () { ... } in global code or from a builtin like
> x.charCodeAt), the CALLPROP can be nopped and the pushed value statically
> resolved to that JSFunction.

Generally, that function object (JSObject), not the underlying compiler-created JSFunction (which is-a JSObject).

This is what branding enables with the property cache, TM's shape-guarded hit case, and related JM cases (I forget whether JM brands or just does its own IC thing).

/be
Comment 2 Brian Hackett (:bhackett) 2011-03-05 16:15:54 PST
Yeah, though branding still requires a shape check on the singleton object so can't be used to totally nop the CALLPROP.  With type information and recompilation, we can keep track of the scripts that depend on, e.g. Math.abs to refer to a particular JSObject, and will recompile those scripts should the info change in the future.

This should subsume branding, so long as the type information stays precise.  Once inference has developed more I hope it will be possible to simplify or remove branding without hurting perf, if doing so will let JSObject shrink more (bug 637931) and reduce the # of dynamic Shape* we make.
Comment 3 Brian Hackett (:bhackett) 2011-04-13 11:05:43 PDT
We're doing this now.

Note You need to log in before you can comment on or make changes to this bug.