Closed Bug 1584240 Opened 5 years ago Closed 5 years ago

2.07 - 2.78% compiler_metrics num_static_constructors (windows2012-32, windows2012-64, windows2012-aarch64) regression on push 88ed3923442a5527d87df3a05e31c7732239b953 (Thu September 26 2019)

Categories

(Firefox Build System :: Toolchains, defect)

defect
Not set
normal

Tracking

(firefox71 wontfix)

RESOLVED WONTFIX
mozilla71
Tracking Status
firefox71 --- wontfix

People

(Reporter: marauder, Unassigned)

References

(Regression)

Details

(Keywords: perf-alert, regression)

We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=88ed3923442a5527d87df3a05e31c7732239b953

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

3% compiler_metrics num_static_constructors windows2012-32 debug 144.00 -> 148.00
2% compiler_metrics num_static_constructors windows2012-64 debug 144.00 -> 147.00
2% compiler_metrics num_static_constructors windows2012-64 debug fuzzing 145.00 -> 148.00
2% compiler_metrics num_static_constructors windows2012-aarch64 debug aarch64 145.00 -> 148.00

You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=23225

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 jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Automated_Performance_Testing_and_Sheriffing/Build_Metrics

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Blocks: 1578356
Component: Performance → Toolchains
Flags: needinfo?(dmajor)
Product: Testing → Firefox Build System
Regressed by: 1573211
Target Milestone: --- → mozilla71
Version: Version 3 → unspecified

Did we not see any regression on opt or pgo builds? If this is only debug, then (even though I am curious) there is no perf implication and it's not worthwhile to investigate.

Flags: needinfo?(dmajor) → needinfo?(marian.raiciof)

[Update]: the alert has been created on opt build.

The graph is similar for opt builds, but perfherder did not create an alert:
https://treeherder.mozilla.org/perf.html#/graphs?timerange=1209600&series=autoland,1844667,1,2&series=autoland,1844698,1,2&series=autoland,1920975,1,2&highlightAlerts=1&zoom=1569431961456,1569442729183,102.40712203022207,151.18339855703138

Should this alert be closed as won't fix or is a candidate for further investigations ?

Flags: needinfo?(marian.raiciof) → needinfo?(dmajor)

Ah, ok, opt builds are more interesting. It looks like we only gained +2 there.

I will take a look. (But I think it's ok if this takes more than 3 days, there are other regressions that I need to investigate first)

"But I think it's ok if this takes more than 3 days, there are other regressions that I need to investigate first"
That's fine, no problem.
Thanks!

In opt we gained constructors for

FUNC 12ec300 41 0 static void mozilla::dom::RequestManager<mozilla::dom::StatsRequest,nsMainThreadPtrHandle<mozilla::dom::WebrtcGlobalStatisticsCallback>,mozilla::dom::WebrtcGlobalStatisticsReport,nsTSubstring<char16_t> >::`dynamic initializer for 'sRequests'()
FUNC 12ec380 41 0 static void mozilla::dom::RequestManager<mozilla::dom::LogRequest,nsMainThreadPtrHandle<mozilla::dom::WebrtcGlobalLoggingCallback>,mozilla::dom::Sequence<nsTString<char16_t> >,const nsTSubstring<char> >::`dynamic initializer for 'sRequests'()

https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/media/webrtc/signaling/src/peerconnection/WebrtcGlobalInformation.cpp#140

They seem to be doing a malloc of 120 bytes each (on 64-bit) in their initializers. I'll keep looking...

These are false positives. The "new" constructors were still present before the patch landed, but clang had misreported their names in such a way that the constructor counting code didn't count them before.

For example, this name is reported properly in clang 9:

xul!mozilla::dom::RequestManager<...>::`dynamic initializer for 'sRequests'

Where clang 8 had previously reported the same code as:

xul!mozilla::dom::WebrtcGlobalChild::WebrtcGlobalChild+0x31
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dmajor)
Resolution: --- → WONTFIX
Blocks: 1592626
No longer blocks: 1592626
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.