Closed Bug 941824 Opened 6 years ago Closed 6 years ago

Add a way to protect ourselves from known bad patterns in unified builds

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla28

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

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

Attachments

(1 file)

The idea is to define a preprocessor macro when in unified mode which we can use to check certain patterns that we know must never occur in unified builds.
Comment on attachment 8336314 [details] [diff] [review]
#define MOZ_UNIFIED_BUILD for everything that is compiled in unified mode; r=gps

Greg, we need this pretty badly, so fast reviews are highly appreciated! :)
Attachment #8336314 - Flags: review?(gps)
Attachment #8336314 - Flags: review?(gps) → review+
Blocks: 941854
https://hg.mozilla.org/mozilla-central/rev/6ea48618123c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
this is causing a regression from talos numbers in modified page list bytes by 27%:
https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/zMyoTUZQgKc

http://graphs.mozilla.org/graph.html#tests=[[271,131,25]]&sel=none&displayrange=7&datatype=running

For reference this is the history of adding this counter: https://bugzilla.mozilla.org/show_bug.cgi?id=558613.

Is this regression desired?
Keywords: perf, regression
Whiteboard: [perf_regression]
It's not possible to cause that regression. However, the change caused all unified sources to be rebuilt, which means a partial clobber. It's very likely that the real cause of the regression is something that landed before this patch, required a clobber but didn't get one.
How can we determine when the last clobber build was done in the sequence of pushes to inbound?
(In reply to comment #7)
> How can we determine when the last clobber build was done in the sequence of
> pushes to inbound?

You can examine each individual build log manually.  I don't know if there is an easier way.
I looked at the build log for this:
https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla-Inbound&full=1

it doesn't appear to be a clobber from looking at the log file.  If there is a way to determine that in the log file, please outline it here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [perf_regression] → [talos_regression]
Not sure why you reopened this bug.

(In reply to Joel Maher (:jmaher) from comment #9)
> I looked at the build log for this:
> https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla-
> Inbound&full=1
> 
> it doesn't appear to be a clobber from looking at the log file.  If there is
> a way to determine that in the log file, please outline it here.

See the entry marked as "Started checking clobber times" in the log.  That code reaches out to a web server giving you a timestamp of the clobberer for the current tree, and we choose whether to clobber based on that.  Please ask one of our sheriffs for a more accurate answer, I haven't done this stuff in a while.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Joel did, the log quoted in comment 9 was not a clobber, neither from the releng side, nor the in-tree CLOBBER file.
Depends on: 942920
I filed bug 942920 to track this, we will need to fix this prior to the next uplift.
No longer depends on: 942920
Depends on: 942920
No longer depends on: 942920
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.