Closed Bug 895159 Opened 8 years ago Closed 7 years ago

Investigate solutions for handling PC's in jit'd JS code during profiler stack walk

Categories

(Firefox OS Graveyard :: General, defect, P5)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED
1.3 C3/1.4 S3(31jan)

People

(Reporter: huseby, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=profiling p=2 s=2014.01.31 u=])

One problem we don't have a solution for yet is handling jit'd JS code when doing stack walks during the profile sig handler.  This bug tracks the work to investigate and find a solution to the problem.

Any suggestions on how this could be done?
We push a pseudoframe entry called js::RunScript before entering JS. We can modify that pseudoframe to contain all the data to unwind from that point. We can use these frames to resume the unwinding. Thus the stack would look like this:

XRE_Main                         --- done
...                               |
event loop                        |
run event                         |
...                               |
JS::RunScript    (Saved Context) Resume unwind from context
JITFrame         (Can't unwind)  Recover all
JITFrame         (Can't unwind)  JIT frames via
JITFrame         (Can't unwind)  Pseudoframes
JITFrame         (Can't unwind)  --- 
VMCall                            |
JS_GetData                        |
PR_Now                          Unwind
Blocks: 896808
Blocks: 904881
Does this work if all we have are a snapshot of the registers and the memory from [SP] up to [SP, #some_reasonable_constant]?  That's what will be dealing with for perf, and it'd be good to have an answer for jitcode there as well.
Blocks: 904894
Can you answer Jed's question in comment 2?
Flags: needinfo?(bgirard)
Whiteboard: c=profiling → [c=profiling s=2013.09.20 p=2]
(In reply to Jed Davis [:jld] from comment #2)
> Does this work if all we have are a snapshot of the registers and the memory
> from [SP] up to [SP, #some_reasonable_constant]?  That's what will be
> dealing with for perf, and it'd be good to have an answer for jitcode there
> as well.

No, the Pseudostack data is not on the stack. Is there anything else we can access other then the area near [SP]?
Flags: needinfo?(bgirard) → needinfo?(jld)
Not without making Gecko-specific changes to the kernel, or trying to generalize that enough to make it upstreamable, neither of which I particularly want to become entangled by if possible.
Flags: needinfo?(jld)
Assignee: jld → nobody
Whiteboard: [c=profiling s=2013.09.20 p=2] → [c=profiling s= p=2]
Status: NEW → RESOLVED
Closed: 7 years ago
Priority: -- → P5
Resolution: --- → WONTFIX
Whiteboard: [c=profiling s= p=2] → [c=profiling p= s=2014.01.31 u=]
This seems to be "fixed", in that we've successfully investigated.   For the Gecko profiler, the approach described in comment #1 is mostly implemented (bug 914561; stay tuned for updated patches).  For perf(1), there isn't a good answer, but that's not as important.
Resolution: WONTFIX → FIXED
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
Whiteboard: [c=profiling p= s=2014.01.31 u=] → [c=profiling p=2 s=2014.01.31 u=]
You need to log in before you can comment on or make changes to this bug.