Thanks, sounds great! Very exciting. On Sat, Feb 7, 2015 at 4:49 PM, Kannan Vijayan <kvija...@mozilla.com> wrote:
> Should be no problem. Optinfo hangs off of the JitcodeGlobalTable's > IonEntry entries. There are also IonCacheEntry structs that we could hang > optinfo for ICs from. We are already hanging some opt-info off of the > BaselineEntry structs. These are used when we fail to Ion-compile - so we > attach the failure reason to the BaselineEntry instead, and it becomes a > "reason this code executed in baseline". Hanging optinfo off of > IonCacheEntry structs would look very similar to this. > > Kannan > > > On 2015-02-07 5:35 AM, Jan de Mooij wrote: > >> 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 >> > > _______________________________________________ > 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
