Closed Bug 1267565 Opened 8 years ago Closed 8 years ago

2.87 - 4% kraken (linux64, windows7-32, windows8-64, windowsxp) regression on push 09aaae546918 (Mon Apr 25 2016)


(Core :: JavaScript Engine, defect)

49 Branch
Not set



Tracking Status
firefox48 --- unaffected
firefox49 --- fixed


(Reporter: jmaher, Assigned: arai)



(Keywords: perf, regression, Whiteboard: [talos_regression])


(1 file)

Talos has detected a Firefox performance regression from push 09aaae546918. As author of one of the patches included in that push, we need your help to address this regression.

This is a list of all known regressions and improvements related to the push:

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see:

Reproducing and debugging the regression:

If you would like to re-run this Talos test on a potential fix, use try with the following syntax:
try: -b o -p win32,linux64,win64 -u none -t dromaeojs[Windows XP,Windows 7,Windows 8],dromaeojs-e10s[Windows XP,Windows 7,Windows 8] --rebuild 5  # add "mozharness: --spsProfile" to generate profile data

(we suggest --rebuild 5 to be more confident in the results)

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:

Then run the following command from the directory where you set up Talos:
talos --develop -e [path]/firefox -a kraken

Making a decision:
As the patch author we need your feedback to help us handle this regression.
*** Please let us know your plans by Friday, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Target Milestone: Firefox 49 → ---
:arai, can you help figure out what is going on here and if we can reduce this regression at all?
Flags: needinfo?(arai.unmht)
Blocks: 1267364, 1263525
as a note the last kraken regression was bug 1262967, we keep getting worse on this test.
With retriggering on awfy I see:!45939565472b

This means it potentially is:
Tooru Fujisawa <> - Tue, 26 Apr 2016 08:08:45 +0900 - rev 294817
Bug 1263525 - Add dedicated function for std_Array self-hosted intrinsic. r=efaust
Sorry, forgot to add the code to retrieve templateObject for array_construct to IonBuilder::inlineArray, and the JIT inlining was disabled.

The inlined JIT code was shared by both Array ctor and std_Array, and the implementation was only ArrayConstructor.  Bug 1267565 separated it into ArrayConstructor and array_construct, and forgot to update IonBuilder::inlineArray.  (I only updated GetTemplateObjectForNative...)

Locally, confirmed the regression in stanford-crypto-pbkdf2 from 98.2 to 114.1, and the fix with this patch.
Assignee: nobody → arai.unmht
Flags: needinfo?(arai.unmht)
Attachment #8745265 - Flags: review?(efaustbmo)
So, this is from bug 1263525.
No longer blocks: 1267364
thanks for the quick fix and narrowing it down!
Comment on attachment 8745265 [details] [diff] [review]
Re-enable JIT inlining for std_Array.

Review of attachment 8745265 [details] [diff] [review]:

::: js/src/jit/MCallOptimize.cpp
@@ +437,5 @@
>      JSObject* templateObject = inspector->getTemplateObjectForNative(pc, ArrayConstructor);
> +    // This is shared by ArrayConstructor and array_construct (std_Array).
> +    if (!templateObject)
> +        templateObject = inspector->getTemplateObjectForNative(pc, array_construct);

please add a blank line below this hunk. This |if (!templateObject)| is associated with the decl, not the failure state.
Attachment #8745265 - Flags: review?(efaustbmo) → review+
and alerts are showing the improvement as well:

thanks for the quick fix!
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.