Nice! I think this will work well for most performance issues/cliffs I'm aware of.
Can we add similar instrumentation for ICs? IonBuilder instrumentation will tell us why we ended up with an IC (that's great), but it'd be neat if we also tracked why the IC didn't attach a stub, for instance: megamorphism (too many stubs), "weird" objects on the proto chain (proxies, hooks), scripted getters/setters etc etc. IC slow paths often show up high in profiles of websites/frameworks and I think having this information is essential. Ideally we'd do the same for Baseline ICs :) Thanks, Jan On Fri, Feb 6, 2015 at 1:20 AM, Shu-yu Guo <s...@mozilla.com> wrote: > Greetings, fellow subtrahend incrementers! > > I recently landed bug 1030389 to track the high-level optimizations > decisions > (i.e., deciding what MIR is emitted) made by IonBuilder. This information > will feed into the profiler and is attached to sampled JIT frames. > > Currently, getprop, setprop, getelem, setelem, and calls are tracked. I > should > like to introduce the API here so that upcoming patches of new > optimizations > like the SIMD.js optimizations are tracked from the beginning. > > High-level description > ---------------------- > > Optimizations are tracked by bytecode location. The API allows each > bytecode > location to track two things: optimization attempts, and type information. > > Each optimization attempt is is a pair of (strategy, outcome). These are > implemented by the enums TrackedStrategy and TrackedOutcome in > js/public/TrackedOptimizationInfo.h. The strategy describes the > optimization > Ion is attempting to emit (e.g., a definite slot load), and the outcome > describes a specific reason for its success or failure (e.g., failed due to > no type info). > > Each bytecode location can accumulate a list of attempts. This list is > terminated by the first successful attempt. The slow path is not encoded as > its own attempt pair and is inferred from a list of attempts whose outcomes > are all failures. That is, if only the slow path succeeded, the attempts > list > will all failed attempts. > > Each tracked type is a triple of (site, MIR type, type set). The site is > described by the enum TrackedTypeSite. > > API > --- > > Add the specific attempts, outcomes, and type sites you need, if not > already > present, to the enums in js/public/TrackedOptimizationInfo.h. > > To start tracking optimizations for a bytecode location, > call |startTrackingOptimizations()|. > > Usually, types are tracked in the beginning by > calling |trackTypeInfo(TrackedTypeSite, MIRType, TypeSet *)|. > > Before attempting to apply a strategy (e.g., before the call to > getPropTryConstant), call |trackOptimizationAttempt(TrackedStrategy)|. By > default, the outcome of the attempt is "generic failure". To refine the > outcome, call |trackOptimizationOutcome(TrackedOutcome)|. > > There is the convenience function |trackOptimizationSuccess()| to track > successes. Be sure to call this on successfully applying an optimization! > In > methods like IonBuilder::jsop_getprop where a series of strategies are > tried > one after another, each |*emitted = true| assignment should be accompanied > by > a call to |trackOptimizationSuccess()|. > > All tracking methods are infallible. OOM during tracking disables > optimization > tracking instead. > > That's it! Instrumentation bugs also make great first bugs, and I would be > happy to mentor. > > -- > shu > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
