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.
Created attachment 8336314 [details] [diff] [review] #define MOZ_UNIFIED_BUILD for everything that is compiled in unified mode; r=gps
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)
Status: NEW → RESOLVED
Last Resolved: 4 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
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
Last Resolved: 4 years ago → 4 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.
I filed bug 942920 to track this, we will need to fix this prior to the next uplift.
You need to log in before you can comment on or make changes to this bug.