Teach browsertime to collect JS tracing statistics/jitspew

[ncalexan]

Bug 1545091 added support for very detailed tracing of the Gecko JS engine. This ticket tracks teaching the Mozilla browsertime fork to collect the jitspew logs.

[dpalmeiro]

If we do this, we should try and parse the tracelogger data from the gecko profile. There already is code in perf-html to do this, it would be great if we could use pull that out of the UI and share it.

[ncalexan]

If we do this, we should try and parse the tracelogger data from the gecko profile. There already is code in perf-html to do this, it would be great if we could use pull that out of the UI and share it.

Post-processing really feels like follow-up to collection, at best, and not part of the scope of browsertime, at worst. That is, do we just want to collect tracelogger data? Or do we want to extract some metric from tracelogger data?

[dpalmeiro]

If we do this, we should try and parse the tracelogger data from the gecko profile. There already is code in perf-html to do this, it would be great if we could use pull that out of the UI and share it.

Post-processing really feels like follow-up to collection, at best, and not part of the scope of browsertime, at worst. That is, do we just want to collect tracelogger data? Or do we want to extract some metric from tracelogger data?

The unfortunate consequence of having the JS engine spew this data directly is that the --enable-jitspew flag must be enabled in the mozconfig. If it is, then we can just collect and that's fine. However, the same data is also available embedded into the gecko profile without any compilation flags. This is easier to collect, but will require some post-processing to output in a Jitspew equivalent form.