471645 - Need to indicate where JS execution has caused a trace abort

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Oliver Hunt]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081225 Firefox/4.0.1

When writing performance intensive JS there are a number of tools available (profilers exist for firefox, webkit, and opera), but those tools can really only point out algorithmic faults.  In the case of TraceMonkey it's possible for "ordinary" looking code to cause a trace to abort, thus killing performance.  

Unfortunately there is currently no way for a web developer to know when/where this is occuring -- even with a custom build that has all the jit and trace logging on the abort information points to where the tracer itself fails, not the js that caused the failure.

For that reason I feel it would be great if there was a mechanism (warnings perhaps?) to inform the developer where in their js a trace aborted.

Reproducible: Always

Steps to Reproduce:
1. Find JS that fails to trace -- http://nerget.com/rayjs/rayjs.html should do it
2. Run said JS
Actual Results:  
There is no feedback for the average developer to indicate that tracing failed

Expected Results:  
Feedback to indicate
 * Where the trace aborted
 * Why it aborted

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

This is a fine idea. The implementation should be pretty straightforward, the only question I have is how to best expose this to developers.

Comment 2

[Oliver Hunt]

Indeed, that was the only issue i could see -- I imagine it could be exposed as API or some such for FireBug etc to hook into, but i think even a warning would suffice (just once per abort location)

Of course I know nothing about how that would happen so i'm just hand waving :D

Comment 3

[Jeff Walden [:Waldo]]

javascript.options.jit.warn-on-aborts or somesuch for a preference, defaulting to false, make it a JS_SetOptions or something like that, I guess; basically analogous to how strict warnings and such, with which developers should already be familiar (I hope).  I'd be extremely surprised if we wanted this happening by default given its perfy impact.

Comment 4

[David Mandelin [:dmandelin]]

Be careful--aborts are not the only cause of bad perf. Falling off trace for various reasons is important, too.

If I were a developer using TM, I think I'd want to have an API to enable and disable abort tracking in both JSAPI and JS. Then, when an abort occurs, I want an arbitrary callback to get called. For Firebug, it would be great to collect the aborts in a dialog with sorting/categorization, etc. 

One problem is that calling back random stuff can perturb TM, so calling back immediately might be a problem. It would be safer to collect the aborts in a data structure, and then add an API for reading it.

Comment 5

[Rob Campbell [:rc] (:robcee)]

I'm wondering how we'd see this in Firebug or some other profiling tool. Could there be a class of jit warnings as Waldo suggests? As I understand it, turning on JSD disables tracing, so maybe something we could view after-the-fact as Dmandelin suggests would be a good solution. One concern about dumping warnings to the error console is that once they're there, they're not very useful for analysis. Context is already gone.

I could see doing this in a kind of "suspend-firebug-and-profile-tracing" mode that pops back a bunch of structures onto the console for inspection. It'd be really nice if we could combine that with regular profiling, but I'm not sure if that would disable tracing altogether or not.

Good suggestion, Oliver. As part of a code analysis tool, providing suggestions on how to improve code for traceability would be pretty useful.

Comment 6

[Oliver Hunt]

I'm personally in favour of dave's post-execution suggestion.  To a certain extent this sort of information could be considered analogous to profiling - eg. we expect profiling info to be available after execution, not during (note: i'm not saying this should necessarily be part of profiling, just that the semantics are similar).  A similar concept would be Shark's profiling output which includes annotations indicating code that could cause bad perf (examples i've seen it produce are unaligned loops, float/double conversion, etc)

Comment 7

[David Mandelin [:dmandelin]]

(In reply to comment #6)
> A similar concept would be Shark's profiling output
> which includes annotations indicating code that could cause bad perf (examples
> i've seen it produce are unaligned loops, float/double conversion, etc)

Ooh, I like it. Especially because some aborts are worse than others. Some are pretty benign and are usually temporary, while others persist and really do prevent jitting. Whichever way we do it, I like the idea focusing on bad perf vs. raw aborts, and hopefully putting a bit of intelligence in the algorithm to filter things and make the results easier to use.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Obsolete with the removal of tracejit.