Last Comment Bug 797876 - [jsdbg2] Introduce a new API for tracing profiling
: [jsdbg2] Introduce a new API for tracing profiling
Status: NEW
[firebug-p1]
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Naveed Ihsanullah [:naveed]
:
Mentors:
Depends on: 716647 881370
Blocks: firebug-gaps 800200
  Show dependency treegraph
 
Reported: 2012-10-04 08:24 PDT by Jan Honza Odvarko [:Honza]
Modified: 2014-07-29 14:07 PDT (History)
19 users (show)
bobbyholley: needinfo? (nihsanullah)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jan Honza Odvarko [:Honza] 2012-10-04 08:24:23 PDT
One of the dev-tools team goals is to get rid of JSD1 and use only JSD2 + RDP.

However, JSD1 also includes profiling features (COLLECT_PROFILE_DATA flag) that is used e.g. in Firebug. These API should be replace by new API so, Firebug and other tools can continue to provide the same results.

Honza
Comment 1 Jan Honza Odvarko [:Honza] 2012-10-04 08:28:52 PDT
Example of Firebug profiler output

1) Install Firebug:
https://addons.mozilla.org/en-us/firefox/addon/firebug/

2) Load this page:
https://getfirebug.com/tests/head/console/api/profile.html

Follow instructions on the page

Honza
Comment 2 Jim Blandy :jimb 2012-10-09 09:28:22 PDT
It's worth observing, for the long term, that this data could be trivially provided by the Debugger API, but Debugger is not suitable here because it imposes the overhead of debug mode --- even though this application would never need the features that make debug mode necessary.

In other words, if debug mode could be turned on and off with debuggee frames on the stack, we could simply use Debugger here.
Comment 3 Rob Campbell [:rc] (:robcee) 2012-11-01 15:11:34 PDT
One other option, how necessary is this for Firebug? If we provided an alternative Profiler would that be sufficient? It seems costly to keep JSD1 hanging around for this one feature if alternatives are available.
Comment 4 Jan Honza Odvarko [:Honza] 2012-11-02 00:13:28 PDT
(In reply to Rob Campbell [:rc] (:robcee) from comment #3)
> One other option, how necessary is this for Firebug?
I think that existing Firebug users would complain if the
Profiler is removed or providing different kind of results.

> If we provided an alternative Profiler would that be sufficient?
> It seems costly to keep JSD1 hanging around for this one feature
> if alternatives are available.
Yes, my goal is to get rid of JSD1 in Firebug so, it can be
removed from Firefox eventually.

I have been discussing the alternatives and the result was that
implementing new API that provides the same kind of profiler-results
as Firebug has now (see Comment #1) is relatively simple.

It also make sense to me if Firebug continues to support its profiler while built-in dev tools introduce new/different (SPS) profiler.

Honza
Comment 5 Jan Honza Odvarko [:Honza] 2012-12-17 12:54:59 PST
@Naveed: any news on the API?

(it would be still great for Firebug to have it)

Honza
Comment 6 Bobby Holley (PTO through June 13) 2013-05-17 07:29:29 PDT
Naveed, can we get resources behind this? Along with bug 637572, this is the last remaining blocker for removing JSD, which is a constant source of pain when modernizing XPConnect and DOM/JS interaction. It sounds like bug 637572 is well underway, and it would be awesome if we could make progress on these bugs simultaneously.
Comment 7 Jan Honza Odvarko [:Honza] 2013-06-05 05:17:49 PDT
I have implemented a simple Profiler in JS that is based on Debugger.onEnterFrame and Debugger.Frame.onPop APIs.

Here is the source module:
https://github.com/firebug/firebug/blob/jsd2/extension/content/firebug/console/profilerEngine.js

It works for simple cases, STR:

1) Clone Firebug repo: git@github.com:firebug/firebug.git and switch to jsd2 branch.
https://github.com/firebug/firebug/tree/jsd2

2) Install Firebug from the source (I can provide XPI if it helps)

3) Run Firebug, load this page and follow instructions on it.
https://getfirebug.com/tests/manual/issues/6496/issue6496.html

Results are properly logged into the Console panel

---

However, I am also observing weird browser freezes.

1) Install Firebug, just like in the previous case
2) Select and enable the Console panel
3) Load https://getfirebug.com/tests/manual/issues/6496/issue6496.html
4) Press the Profile button
5) Just move mouse over the page content area
6) The browser freezes.

Anyone knows what's happening under the hood?
And what could cause the browser to freeze?

Honza
Comment 8 Jan Honza Odvarko [:Honza] 2013-06-05 05:20:16 PDT
Forgot to add.

I am seeing that (just before the browser freezes) some frames passed into onEnterFrame and onPop are not live (frame.live == false)

Honza
Comment 9 Jan Honza Odvarko [:Honza] 2013-06-10 04:18:19 PDT
Jim, do you have any insights what the problem
(described in comment #7) could be?

Honza
Comment 10 Jim Blandy :jimb 2013-06-10 09:39:08 PDT
The freezes with the console enabled could be bug 877773; do they still occur? If not, I don't think there's any way to tell without profiling.

(In reply to Jan Honza Odvarko from comment #8)
> I am seeing that (just before the browser freezes) some frames passed into
> onEnterFrame and onPop are not live (frame.live == false)

This is very disturbing. The frame passed to onEnterFrame and the 'this' frame for onPop should always be live, at least until the onPop handler returns. Can you reproduce this reliably?
Comment 11 Jan Honza Odvarko [:Honza] 2013-06-10 09:46:02 PDT
(In reply to Jim Blandy :jimb from comment #10)
> This is very disturbing. The frame passed to onEnterFrame and the 'this'
> frame for onPop should always be live, at least until the onPop handler
> returns. Can you reproduce this reliably?
Yes

Unfortunately I am still seeing the problem.

Tested with built from http://hg.mozilla.org/mozilla-central/rev/252b1ac4d537
24.0a1 (2013-06-10)

Honza
Comment 12 Jan Honza Odvarko [:Honza] 2013-08-29 01:30:50 PDT
(In reply to Jan Honza Odvarko from comment #11)
> (In reply to Jim Blandy :jimb from comment #10)
> > This is very disturbing. The frame passed to onEnterFrame and the 'this'
> > frame for onPop should always be live, at least until the onPop handler
> > returns. Can you reproduce this reliably?
> Yes
> 
> Unfortunately I am still seeing the problem.
Update: this problem no longer appear.

As discussed with Nick Fitzgerald and Jim Blandy at the DevTools meetup in Paris:

1) Tracing profiler implemented in JS based on JSD2 API works (used API: onEnterFreame and onPop [1]). One related bug described in this thread (above) has been fixed.

2) Unfortunately the (JS) implementation forces JIT compilation to be switched off, which can negatively influence the result data. The profiler should always profile with JIT in place.  

3) The final solution seems to be having C++ level implementation working as follows:
 - the client (a dev tool) starts profiling by calling JSD2 API
 - as JS is running JSD2 is collecting profiling data: function calls, timing, etc.
 - the client stops the profiling and enumerates collected data (similarly how JSD1 API worked).


[1] https://github.com/firebug/firebug/blob/jsd2/extension/content/firebug/console/profilerEngine.js


Honza
Comment 13 Steve Fink [:sfink] [:s:] 2013-08-29 09:29:03 PDT
(In reply to Jan Honza Odvarko from comment #12)
> 2) Unfortunately the (JS) implementation forces JIT compilation to be
> switched off, which can negatively influence the result data. The profiler
> should always profile with JIT in place.  

Is this accurate? My understanding of what happens is that when you start debugging, the *current* JIT code is discarded, but the code is re-JITted into a somewhat slower form (in particular, one that contains the needed entry/exit points, which may have been inlined away entirely in the fully optimized version.) So it's not accurate to say that JIT compilation is switched off. It's more like there's a (generally quite short) stutter before the code begins running at high (but not full) speed again. Is that intrusion considered too severe?

Also, there's a difference between baseline JITted code and full Ion JITted code, but I'd just spread misinformation if I tried to describe how that works with respect to debug mode. jimb?

> 3) The final solution seems to be having C++ level implementation working as
> follows:
>  - the client (a dev tool) starts profiling by calling JSD2 API

New API entries, you mean? (As in, ones that do not currently exist?)

>  - as JS is running JSD2 is collecting profiling data: function calls,
> timing, etc.

This will likely never be *completely* free, since the necessary information may have been completely inlined away and so you'll need to recompile into a different form anyway, but it should be less invasive this way as compared to calling arbitrary JS at every entry/exit event.
Comment 14 Jan Honza Odvarko [:Honza] 2013-08-30 01:10:40 PDT
(In reply to Steve Fink [:sfink] from comment #13)
> (In reply to Jan Honza Odvarko from comment #12)
> > 2) Unfortunately the (JS) implementation forces JIT compilation to be
> > switched off, which can negatively influence the result data. The profiler
> > should always profile with JIT in place.  
> 
> Is this accurate? My understanding of what happens is that when you start
> debugging, the *current* JIT code is discarded, but the code is re-JITted
> into a somewhat slower form (in particular, one that contains the needed
> entry/exit points, which may have been inlined away entirely in the fully
> optimized version.) So it's not accurate to say that JIT compilation is
> switched off. It's more like there's a (generally quite short) stutter
> before the code begins running at high (but not full) speed again. Is that
> intrusion considered too severe?
I am CCign fitzgen who did some testing and result analyses.


> Also, there's a difference between baseline JITted code and full Ion JITted
> code, but I'd just spread misinformation if I tried to describe how that
> works with respect to debug mode. jimb?
> 
> > 3) The final solution seems to be having C++ level implementation working as
> > follows:
> >  - the client (a dev tool) starts profiling by calling JSD2 API
> 
> New API entries, you mean? (As in, ones that do not currently exist?)
Yes, new APIs.


> >  - as JS is running JSD2 is collecting profiling data: function calls,
> > timing, etc.
> 
> This will likely never be *completely* free, since the necessary information
> may have been completely inlined away and so you'll need to recompile into a
> different form anyway, but it should be less invasive this way as compared
> to calling arbitrary JS at every entry/exit event.
Comment 15 Jan Honza Odvarko [:Honza] 2014-02-27 06:57:17 PST
Any chance to get more attention to the Profiler API based on JSD2?
(see my comment #12)

Honza
Comment 16 Jan Honza Odvarko [:Honza] 2014-03-20 06:49:03 PDT
Should I change the Component to get more attention to the report?

Honza
Comment 17 Emanuel Hoogeveen [:ehoogeveen] 2014-03-20 07:04:00 PDT
Out of curiosity, since I haven't seen it mentioned here yet, would it be possible and/or useful to give access to the data from the pseudostack used by the existing SPS profiler?
Comment 18 Jan Honza Odvarko [:Honza] 2014-03-21 05:08:48 PDT
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #17)
> Out of curiosity, since I haven't seen it mentioned here yet, would it be
> possible and/or useful to give access to the data from the pseudostack used
> by the existing SPS profiler?
I don't know what exact data you have in mind, but the data Firebug needs (and collected before using JSD1) is:

For every JS function executed within the profiling session:
- callCount
- totalExecutionTime
- totalOwnExecutionTime
- minExecutionTime
- maxExecutionTime

Related to function location:
- filename
- functionName
- line, column

Honza
Comment 19 Emanuel Hoogeveen [:ehoogeveen] 2014-03-21 05:56:10 PDT
Benoit, could you comment on what information the SPS profiler can provide here? Also, is it available in release builds?
Comment 20 Jim Blandy :jimb 2014-03-21 15:53:29 PDT
One fundamental difference between SPS and the JSD1 profiling API is:

- SPS is a sampling profiler. Every millisecond or so we get a signal, and the handler captures some data and logs it. So you get a statistical view of the code, but stuff that happens between samples is invisible.

- JSD's was an exact profiler. It instrumented function entry and exit. It gave you exact call counts.
Comment 21 Benoit Girard (:BenWa) 2014-03-24 14:07:23 PDT
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #19)
> Benoit, could you comment on what information the SPS profiler can provide
> here? Also, is it available in release builds?

What jimb said. The profiler backend is available in all release builds including gecko, fennec, b2g, thunderbird and various gecko based project (except OpenBSD which doesn't build with it because it's not ported).

Native stack unwinding is -optional- and is generally only available on --enable-profiling builds and where we have code to make use the profiling information. The profiler is fully usable without that feature because of the manually annotated functions.
Comment 22 Emanuel Hoogeveen [:ehoogeveen] 2014-03-24 14:15:47 PDT
Thanks, doesn't seem like there's that much overlap with this bug then. I mostly brought it up because I saw bug 948229 coming by, which seemed to take a while to get right - but I guess that's only relevant for profiling JITed code specifically, whereas this bug is about a more general API.
Comment 23 Jan Honza Odvarko [:Honza] 2014-06-30 06:37:39 PDT
Joe, could this be fixed as part for Firebug gaps effort?

Honza

Note You need to log in before you can comment on or make changes to this bug.