1432391 - Slowly growing 2% regression compiler_metrics num_static_constructors (linux32 debug)

Status: RESOLVED INVALID

(Tree Management :: Perfherder, defect)

Description

[Ionuț Goldan [:igoldan]]

This 2% regression has gradually increased since January 10 2018. It affects Linxu 32 DEBUG builds. Bellow are the small regressions which got in, linked to their respective bugs.
Only if you have the time, please consider fixing it, to lessen the overall regression. I understand this is lower priority.

0.5% (from 232 to 233) -> Bug 1429174, Jan 10, more here https://treeherder.mozilla.org/perf.html#/alerts?id=11247
0.5% (from 233 to 234) -> Bug 1427344 , Jan 12 more here
https://treeherder.mozilla.org/perf.html#/alerts?id=11248
1% (from 234 to 236) -> Bug 1412726, Jan 12, more here
https://treeherder.mozilla.org/perf.html#/alerts?id=11249
1% (from 236 to 237) -> Bug 1430312, Jan 13, more here
https://treeherder.mozilla.org/perf.html#/alerts?id=11250

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #0)
> 1% (from 236 to 237) -> Bug 1430312, Jan 13, more here
> https://treeherder.mozilla.org/perf.html#/alerts?id=11250

You can ignore this one ^^^ This was us adding a StaticRefPtr -- and according to our documentation, StaticRefPtr is specially written so that it won't produce a static initializer **in release builds**:
https://dxr.mozilla.org/mozilla-central/rev/5faab9e619901b1513fd4ca137747231be550def/xpcom/base/StaticPtr.h#21-22

Apparently it does produce one in debug builds, but that's not a problem because our users don't run debug builds. :)

Comment 2

[Kris Maglione [:kmag]]

I came here to say the same thing as dholbert. This is the expected behavior in debug builds.

Comment 3

[Mike Hommey [:glandium]]

FWIW, the one from bug 1427344 also affects opt builds, but is kind of a false regression. In the build before the landing, the .init section contained:
0000000000964068 <_init>:
  964068:	48 83 ec 08          	sub    $0x8,%rsp
  96406c:	e8 f7 63 02 00       	callq  98a468 <call_gmon_start>
  964071:	e8 1a 65 02 00       	callq  98a590 <frame_dummy>
  964076:	e8 45 2f 19 04       	callq  4af6fc0 <__do_global_ctors_aux>
  96407b:	48 83 c4 08          	add    $0x8,%rsp
  96407f:	c3                   	retq   

The last function iterating the constructors in the .ctors section, which, practically speaking, was empty. The constructors were all already in the .init_array section. That's what we look at for the num_static_constructors count.

In the build for the landing, the same section looks like:
0000000000964098 <_init>:
  964098:	48 83 ec 08          	sub    $0x8,%rsp
  96409c:	e8 f7 63 02 00       	callq  98a498 <call_gmon_start>
  9640a1:	48 83 c4 08          	add    $0x8,%rsp
  9640a5:	c3                   	retq   

The .ctors section was removed, so there is no call to __do_global_ctors_aux, and the frame_dummy call also disappeared, but it moved to the .init_array section. So yes, we now count one more initializer because what used to be called from .init is not called through .init_array.