Re: Tracing execution

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

xolotl
Yes this is what I was looking for but how would you invoke it from JS?
This is a C-level facility. I guess you need to add a corresponding top-
level method (i.e., in the global object) to the JS language. Is there
a tutorial somewhere on how to do that in SpiderMonkey?

-- O.L.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

Donny Viszneki
In the Script tab of Firebug, you can "break on next." That halts
Javascript execution as soon as the next event fires.

In other tabs there are other "break on .." buttons that do different things.

Unfortunately something like a short setInterval() can really
interrupt you if what you want to do is catch a mouse click. Best way
to deal with that is anyone's guess.

On Thu, Jul 28, 2011 at 2:48 PM, Olivier Lefevre <[hidden email]> wrote:

> How difficult would it be to add functionality to SpiderMonkey
> to trace JS execution, for use within the Web Console or Firebug
> Console? There are various hacks to do this in JS but they are
> awkward and the JS engine looks like the logical place to do it.
>
> Thanks,
>
> -- O.L.
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>



--
http://codebad.com/
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

Miles Thornton
In reply to this post by xolotl
> You're correct about the reasoning for the compile-time option. It was
> judged to be too much overhead for the interpreter. For the JITs, if it
> is unused then it's only a quick check during compilation; the generated
> JIT code doesn't change. If it *is* used, the JIT code is deoptimized a
> fair amount. (But you'll still be JITted, unlike eg debug mode which
> will disable the tracer entirely.)

I've been following this thread with interest.
I've been developing a basic debugger for our application which embeds
Spidermonkey (I've just upgraded to Spidermonkey 1.8.5) and I've been
pondering if it would be possible to also create a profiler.
This looks like it fits the bill perfectly.
I just want to confirm my understanding of this. Can anyone confirm/
correct the following which is what I *think* is possible?

1. I can trace function entering/leaving by using
JS_SetFunctionCallback to register a hook but to do that I would have
to recompile Spidermonkey with MOZ_TRACE_JSCALLS defined.
2. If it is used performance will be hit but JIT is still active
3. If it is NOT used there there is no effect on performance (well
negligable anyway). The last thing I want to do is to slow down
scripts if the profiler is not being used.
4. This is not possible if the script is in debug mode (by calling
JS_SetRuntimeDebugMode and JS_SetDebugMode) as the tracer is disabled?
That's how I interpret the previous post. Is that correct?
If so is there any other way of doing it? If not, it doesn't matter.
I'm happy to have to run the 'profiler' separately from a 'debugger'.
I'm just curious.

Miles

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

xolotl
In reply to this post by xolotl
On 8/2/2011 4:59 PM, Donny Viszneki wrote:
> In the Script tab of Firebug, you can "break on next." That halts
> Javascript execution as soon as the next event fires.

Thanks but I find heavy use of the debugger mind-numbing. I would
much rather look at a nice printout of traces.

-- O.L.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

Steve Fink-4
In reply to this post by xolotl
On 08/01/2011 04:14 PM, Olivier Lefevre wrote:
> Yes this is what I was looking for but how would you invoke it from JS?
> This is a C-level facility. I guess you need to add a corresponding top-
> level method (i.e., in the global object) to the JS language. Is there
> a tutorial somewhere on how to do that in SpiderMonkey?
>
> -- O.L.

Sorry, this mechanism is not accessible via JS. It cannot call out to JS
code because that would interfere with execution too much. (It would
force us to maintain consistent internal state, which would defeat the
purpose of the feature.) If you want something accessible from JS,
you'll currently need to use JSD, which will disable the tracing JIT and
have a small performance impact on the method JIT. (But getting a
callback for every function call is already going to have a fairly high
perf impact, even if your callback does very little.)

There is also the jsdbg2 API that just landed -
https://wiki.mozilla.org/Debugger

It will probably end up with similar characteristics as JSD, and I don't
think it's exposed quite yet. (See bug 679031.)
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

Steve Fink-4
In reply to this post by Miles Thornton
On 08/03/2011 08:37 AM, Miles wrote:

>> You're correct about the reasoning for the compile-time option. It was
>> judged to be too much overhead for the interpreter. For the JITs, if it
>> is unused then it's only a quick check during compilation; the generated
>> JIT code doesn't change. If it *is* used, the JIT code is deoptimized a
>> fair amount. (But you'll still be JITted, unlike eg debug mode which
>> will disable the tracer entirely.)
>
> I've been following this thread with interest.
> I've been developing a basic debugger for our application which embeds
> Spidermonkey (I've just upgraded to Spidermonkey 1.8.5) and I've been
> pondering if it would be possible to also create a profiler.
> This looks like it fits the bill perfectly.
> I just want to confirm my understanding of this. Can anyone confirm/
> correct the following which is what I *think* is possible?
>
> 1. I can trace function entering/leaving by using
> JS_SetFunctionCallback to register a hook but to do that I would have
> to recompile Spidermonkey with MOZ_TRACE_JSCALLS defined.

If by "function" you mean "Javascript function", then yes. It won't
track calls to native code. (Actually, what's currently there might get
a couple of them, but claim them to be the calling JS function. I can't
remember the current state.)

The easiest way to get MOZ_TRACE_JSCALLS defined is to configure with
--enable-trace-jscalls

> 2. If it is used performance will be hit but JIT is still active

Yes, though the implication that the JIT will be inactive using another
approach, namely JSD, is not entirely correct -- JSD disables the
tracing JIT, but only slightly slows down the method JIT.

> 3. If it is NOT used there there is no effect on performance (well
> negligable anyway). The last thing I want to do is to slow down
> scripts if the profiler is not being used.

I confess I haven't measured it, but I expected it to induce enough of a
slowdown that I hid it behind MOZ_TRACE_JSCALLS. If there were really no
impact, I would just have it available by default.

Still, I'd be surprised if it were more than a few percentage points.

> 4. This is not possible if the script is in debug mode (by calling
> JS_SetRuntimeDebugMode and JS_SetDebugMode) as the tracer is disabled?
> That's how I interpret the previous post. Is that correct?
> If so is there any other way of doing it? If not, it doesn't matter.
> I'm happy to have to run the 'profiler' separately from a 'debugger'.
> I'm just curious.
>
> Miles
>

If I am understanding correctly, then no, this is not correct. The
JS_SetFunctionCallback callback will still fire when in debug mode. Or
it's supposed to, at least. (There's been at least one bug in that.)

You are correct that the tracer will be disabled, but
JS_SetFunctionCallback hooks into the interpreter and both JITs separately.

I am working on a couple of other routes to get profiling for JS. One is
bug 642054, which is probably exactly what you want -- a profiler for
JS. But it's further out. I'm also exposing JIT information to various
external native profilers, so you can tell what JS function is executing
in their outputs -- oprofile, vtune, shark, callgrind, etc. Which isn't
quite what you want, since (1) it only gives the JS function name of the
youngest JS stack frame, not the whole JS stack, and (2) it ironically
gives better information for JITted code than interpreted code because
the interpreted code just shows up as JS_Execute or whatever.

But none of that's done yet. For now, I think you're going down the
right route.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

xolotl
In reply to this post by xolotl
On 8/16/2011 8:44 PM, Steve Fink wrote:
> Sorry, this mechanism is not accessible via JS. It cannot call out to JS code because that would interfere with execution too much. (It would force us to maintain consistent internal state, which would defeat the purpose of the feature.)

Wrt. calling out to JS my wish was very modest: I just wanted a way to turn tracing on and off from JS.

-- O.L.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Tracing execution

reesd
On Aug 16, 3:37 pm, Olivier Lefevre <[hidden email]> wrote:
> On 8/16/2011 8:44 PM, Steve Fink wrote:
>
> > Sorry, this mechanism is not accessible via JS. It cannot call out to JS code because that would interfere with execution too much. (It would force us to maintain consistent internal state, which would defeat the purpose of the feature.)
>
> Wrt. calling out to JS my wish was very modest: I just wanted a way to turn tracing on and off from JS.
>
> -- O.L.

I assume you could write your tracing in C and then just expose an XPC
interface to JS to turn it on/off, right? If there are threading
concerns, you can mutex around setting that variable. Then the C side
when the variable changes you can register or unregister the callback.

d
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine