Open
Bug 797876
Opened 12 years ago
Updated 2 years ago
[jsdbg2] Introduce a new API for tracing profiling
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: Honza, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [firebug-p1])
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
Reporter | ||
Updated•12 years ago
|
Assignee: nobody → naveed
Reporter | ||
Comment 1•12 years ago
|
||
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
Updated•12 years ago
|
Assignee: naveed → nihsanullah
Comment 2•12 years ago
|
||
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•12 years ago
|
||
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.
Reporter | ||
Comment 4•12 years ago
|
||
(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
Reporter | ||
Comment 5•12 years ago
|
||
@Naveed: any news on the API?
(it would be still great for Firebug to have it)
Honza
Comment 6•12 years ago
|
||
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.
Flags: needinfo?(nihsanullah)
Reporter | ||
Comment 7•12 years ago
|
||
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
Reporter | ||
Comment 8•12 years ago
|
||
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
Reporter | ||
Comment 9•12 years ago
|
||
Jim, do you have any insights what the problem
(described in comment #7) could be?
Honza
Flags: needinfo?(jimb)
Comment 10•12 years ago
|
||
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?
Flags: needinfo?(jimb)
Reporter | ||
Comment 11•12 years ago
|
||
(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
Updated•11 years ago
|
Reporter | ||
Comment 12•11 years ago
|
||
(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•11 years ago
|
||
(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.
Reporter | ||
Comment 14•11 years ago
|
||
(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.
Reporter | ||
Comment 15•11 years ago
|
||
Any chance to get more attention to the Profiler API based on JSD2?
(see my comment #12)
Honza
Reporter | ||
Comment 16•11 years ago
|
||
Should I change the Component to get more attention to the report?
Honza
Whiteboard: [firebug-p1]
Comment 17•11 years ago
|
||
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?
Updated•11 years ago
|
Component: Developer Tools → JavaScript Engine
Product: Firefox → Core
Summary: Introduce new API for JS content Profiling → [jsdbg2] Introduce new API for JS content Profiling
Reporter | ||
Comment 18•11 years ago
|
||
(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•11 years ago
|
||
Benoit, could you comment on what information the SPS profiler can provide here? Also, is it available in release builds?
Flags: needinfo?(bgirard)
Comment 20•11 years ago
|
||
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•11 years ago
|
||
(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.
Flags: needinfo?(bgirard)
Comment 22•11 years ago
|
||
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.
Updated•11 years ago
|
Summary: [jsdbg2] Introduce new API for JS content Profiling → [jsdbg2] Introduce a new API for tracing profiling
Reporter | ||
Comment 23•11 years ago
|
||
Joe, could this be fixed as part for Firebug gaps effort?
Honza
Updated•11 years ago
|
Blocks: firebug-gaps
Updated•7 years ago
|
Flags: needinfo?(nihsanullah)
Updated•7 years ago
|
Assignee: nihsanullah → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•