Closed Bug 1068885 Opened 10 years ago Closed 2 years ago

[Meta] Improve profiler interaction with jitcode

Categories

(DevTools :: General, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: djvj, Unassigned)

References

Details

(Keywords: meta)

This bug has been created to relate together, in a single place, a concerted effort to improve the Firefox profiler dev-tool's interaction with jitcode.

The justification for this work and the end-goals are a bit involved, and I'll summarize them here.

Current State of Affairs
------------------------

1. The pseudostack-based profiler is error-prone.

The pseudostack approach to profiling basically involves instrumenting jitcode so that upon entry to and exit from functions, we push and pop entries in a separate pseudo-stack that mirrors the jitcode frames on the C stack.

This approach, while a fine way of getting a basic profiler implementation up and going, poses a number of security issues.  In particular, there are many areas in the JS engine where the jitcode C-stack is explicitly operated on by various mechanisms - OSR entries, bailouts, invalidations, and exceptions being the main examples.

The interactions between these cases has led to a steady stream of ss bugs.  These bugs arise from the fundamental issue of keeping two stacks in sync when one of them gets manipulated in subtle and hard-to-reason-about ways through interactions and transitions between C++ code and jitcode.

2. The pseudostack-based profiler is imprecise

For performance reason, the pseudostack push/pop instrumentation on Ion jitcode can only happen when we enter/leave the main piece of jitcode.  We used to have push/pop instrumentation around embedded inline functions as well, but this turned to be a heavy performance skew, and we turned it off.

So currently, we "lose" inline frames during profiling.  If we have an actual call-stack
f() => g() => h() => i(), and |f| inlines the call to g() and the call to h() within |g|, then we get a profiler callstack that looks like f() => i(), which is quite compromised.

3. The profiler doesn't tell us where we are spending time in slowpath code

If we are spending a lot of time in a particular region of jitcode, and this problem is exacerbated because that region of jitcode is a slowpath that was generated due to bad type information (or some other de-optimization), then the profiler has no way of telling the developer.  Research intern Vincent St.Amour worked on a project called jit-coach to develop the infrastructure to enable the tracking of slow jitcode.  We would like to see these features eventually integrated directly with the devtools UI.

4. The profiler doesn't handle AsmJS code.

5. The profielr frontend (UI) doesn't yet visualize any of this information (naturally since it doesn't exist yet).

This is a problem luke has worked on and largely landed as part of this project.


Approach to Fixing
------------------

To address points 1 and 2, we have been working on switching from a pseudostack approach to a more lightweight one where the profiler is taught how to walk JS jitcode stack directly, collect return addresses into jitcode for all relevant frames, and translate that list of return addresses into a logical JS call stack.

This work is being done by me under meta bug 994136.  The implementation of a mapping from jitcode native addresses to bytecode logical sites is already done (bug 1004831).  I am currently working on implementing the stack-walking portion which will allow the profiler to collect jitcode return addresses (bug 1057082).

Work on point 3 was started by Vincent St.Amour (:vstamour), dubbed "jit coach", and has now been taken over by Shu-yu Guo (:shu), as part of bug 1030389.

Work on point 4, as mentioned, is largely complete, by Luke Wagner (:luke).  See bug 1027885.

Work on point 5 will be done by Victor Porof (:vporof) in devtools.  No bug for that yet.


Integration
-----------

The overall path to integration is this: once the SPS pseudostack is removed and the profiler taught to walk JS frames directly, we will have a decent infrastructure on which to add the jitcoach optimization annotation.  The SPS sampler will then be updated to collect all relevant info (JS frames, slowpath info), and shuttle that to the profiler UI, which will render it.

Rough timeline for landing all of this basic infrastructure is end-of-q4, 2014.

I hope to land the pseudostack-replacement by end of October.  Then the jit-coach info will need to be added on top of that by Shu.  Then the data will be shuttled to frontend where Victor can take a crack at visualizing it.
Depends on: 994136, 1030389, 1027885
This is the bug I filed some time back for part 5 (I was under the impression we already had access to some JIT data): bug 1046840
Product: Firefox → DevTools

Looks like everything has been implemented here.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.