820519 - flag profiler frames as on-JIT or off-JIT

Status: RESOLVED INACTIVE

(Core :: JavaScript Engine, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It would be really helpful if we could pass some flag per JS stack frame to the SPS profiler to say whether that frame is in JIT code or outside.  BenWa tells me that we have different ways of manually injecting the JS stack info based on whether we're in jitcode or not, so we should be able to just pass some flag along with each frame maybe?

Would really help with visualizing the results to be able to see when we're on jit vs. off!

Comment 1

[Nicolas B. Pierron [:nbp] {away}]

At the moment we can already determine this by looking at the mixed stack.  Due to the way the stack are mixed we can already determine that the last frame in in JM/Ion/Interpreter based on the way it use to make calls C++ functions.  And we can also determine the entry kind by looking of the C++ frame below the C++ js::RunScript function, which indicates how the script has been entered.

I don't think we need more flags, we just need to set the fp pointer of the JS frame correctly such as we can correctly interleave JS and C++ frames.  Currently we only save a frame pointer with the js::RunScript frame, but idealy we wouldn't have the js::RunScript function, but only the fp of the JS frame which is entering a new mode of evaluation.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Is there enough information for someone not familiar with the JS engine to determine this though?  Enough for the visualization to display on-jit/off-jit graphically, ideally even without symbols being available?  Setting the fp pointer would be a good improvement, but we really want to make this easy to see and understand by users.

Comment 3

[Nicolas B. Pierron [:nbp] {away}]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2)
> Is there enough information for someone not familiar with the JS engine to
> determine this though?  Enough for the visualization to display
> on-jit/off-jit graphically, ideally even without symbols being available? 
> Setting the fp pointer would be a good improvement, but we really want to
> make this easy to see and understand by users.

Currently there is not enough information to determine what is the status of a JSFrame which is in the middle, except when IonActivation appear on the stack.  Without C++ symbols, this is just impossible to determine now.

What do you want to display to users?  I am always scared when I hear that we want to show more internal state to users, especially without C++ symbols on the stack.  My point of view is that a JavaScript developer should only have to deal with JavaScript context, not any internal state of the engine.  If we cannot report the error in JS terms, this is the problem.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Well, we're talking about profiling data here -- being able to know "is my code executing in the fastest way possible" is extremely valuable for developers.  Why it is or isn't is outside the scope of the tool, but whether it is or not is incredibly useful.  If we can do it in a straightforward way, we really should; the user is using the profiler to understand why their code is slow or performing in a certain way.  The more information we can give them to this end, the more useful the tool will be.

Comment 5

[Nicolas B. Pierron [:nbp] {away}]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #4)
> Well, we're talking about profiling data here -- being able to know "is my
> code executing in the fastest way possible" is extremely valuable for
> developers.  Why it is or isn't is outside the scope of the tool, but
> whether it is or not is incredibly useful.  If we can do it in a
> straightforward way, we really should; the user is using the profiler to
> understand why their code is slow or performing in a certain way.  The more
> information we can give them to this end, the more useful the tool will be.

The simplest way to do it without reusing the current inter-leaving of the stack is by pushing on the SPS stack when we EnterIon, Enter JM, enter the interpreter, jump between JM to Ion, or jump between Ion to JM.