Hi Katelyn,
I'm going to refer to what you're talking about with cloning and monomorphism
as the "context sensitivity problem". As far as I know, this is still an open
problem (not in the fundamental sense, just that nobody has a good solution for
it yet) in the JS JITs. The argument types (counting 'this' as an argument) is
one part of the context; the other part being the types of its free variables.
For example, the context sensitivity problem is part of the reason repeated
calls to something like Array.prototype.map is slow, and why any user-written
collections libraries with higher order functions will be slow.
I've experimented with manually hinting functions to be cloned at callsite. We
do this currently in SpiderMonkey only for certain PJS functions, like mapPar.
This is a pretty brittle optimization though, since it can be easily defeated
by wrapping, e.g., function myMapPar(arr, fn) { arr.mapPar(fn); }. I'd love to
solve this problem in general. Such a solution would require:
1) A notion of "context" that's efficient in both time and space (e.g. easy to
compute and cheap to store).
2) A notion of "context" that's robust (e.g. not defeated by wrapping).
3) Ability to determine what functions benefit from being cloned per-context.
PGO sounds like a great way to address 3) that I haven't thought of before. I'd
also love to hear ideas about 1) and 2).
Cheers,
----- Original Message -----
From: "Jason Orendorff" <[email protected]>
To: [email protected], "Robert O'Callahan" <[email protected]>
Cc: "Kannan Vijayan" <[email protected]>, [email protected],
[email protected]
Sent: Friday, June 27, 2014 1:21:02 PM
Subject: Exposing JIT performance faults in profiler/devtools (was: Are you
interested in doing dynamic analysis of JS code?)
On 06/25/2014 05:51 PM, Katelyn Gadd wrote:
> Maybe you could use mutation/method call tracing to do a
> profile-guided-optimization equivalent for JS where you record
> argument types and clone functions per-callsite to ensure everything
> is monomorphic?
Yes, I think this is something that could be done with it.
But! Note that we're separately working on exposing JIT performance
faults in the profiler/devtools---directly reporting the kind of
problems you're thinking about painstakingly inferring. \o/
I don't know how far along it is, and it's maybe too early to guess how
actionable the output will be, but it's a much more certain thing than
this dynamic analysis API. No meta bug, but several people are working
on aspects of it. Maybe Kannan can tell more. (cc-ing him)
-j
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
