All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=918528

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=5d145cfbde51b2e87e79d38d7e97ce304e6016c7b197c3373e475228d74908b9


Bot(s) for this bug's original alert(s):

Google Chrome Linux x64

From the description of https://chromium.googlesource.com/chromium/src/+/85151328ea6fc389e6c51e438bc621254ed4062e:

This CL may cause a small binary size increase, roughly proportional
to how long it's been since our last AFDO profile roll. For larger
increases (around or exceeding 100KB), please file a bug against
gbiv@chromium.org. Additional context:  https://crbug.com/805539 

The increase is ~1MB. gbiv@, could you please take a look? Thanks.

Thanks!

The binary size charts for Chrome have been a bit rocky recently :)

Looks like 900K is roughly an upper-bound on AFDO fluctuations in binary size. Meaning, we went back down a bit, then up, then down, then back up, ... but generally staying within this 900KB of .text band.

Bloaty at the time of regression:
$ ~/environments/bloaty/build/bloaty  LinuxNewProf/chrome -- LinuxOldProf/chrome
     VM SIZE                     FILE SIZE
 --------------               --------------
  [ = ]       0 .debug_loc    +3.93Mi  +0.9%
  [ = ]       0 .debug_ranges +2.75Mi  +3.7%
  [ = ]       0 .debug_info   +2.31Mi  +0.1%
  +0.9%  +987Ki .text          +987Ki  +0.9%
  [ = ]       0 .debug_line    +689Ki  +0.4%
  [ = ]       0 .debug_abbrev +47.9Ki  +0.1%
  +0.0% +3.92Ki .rodata       +3.92Ki  +0.0%
  +0.0% +2.25Ki .rela.dyn     +2.25Ki  +0.0%
   +28% +1.77Ki google_malloc +1.77Ki   +28%
  +0.0% +1.50Ki .data.rel.ro  +1.50Ki  +0.0%
  [ = ]       0 [Unmapped]       +213  +5.5%
  +0.1%     +72 .eh_frame         +72  +0.1%
 -33.9% -1.50Ki [LOAD [RW]]         0  [ = ]
  [ = ]       0 .symtab       -15.4Ki  -0.1%
  [ = ]       0 .debug_frame  -29.2Ki  -0.2%
  [ = ]       0 .debug_str    -51.3Ki  -0.0%
  [ = ]       0 .gdb_index    -73.4Ki  -0.0%
  [ = ]       0 .strtab        -149Ki  -0.3%
  +0.7%  +995Ki TOTAL         +10.4Mi  +0.2%

Comparing the sizes of Chrome binaries at the time of regression:

$ du Linux*/chrome.stripped
139996  LinuxNewProf/chrome.stripped
139992  LinuxNoAFDO/chrome.stripped
139000  LinuxOldProf/chrome.stripped

...And on ToT:

$ du LinuxToT*/chrome.stripped
139196  LinuxToT/chrome.stripped
139680  LinuxToTNoAFDO/chrome.stripped

Bloaty:

     VM SIZE                         FILE SIZE
 --------------                   --------------
  +0.1% +20.1Ki .rela.dyn         +20.1Ki  +0.1%
  +0.1% +8.27Ki .data.rel.ro      +8.27Ki  +0.1%
  +945% +3.77Ki [LOAD [RW]]           +32  +7.8%
  +0.0% +2.23Ki .rodata           +2.23Ki  +0.0%
   +37% +1.73Ki google_malloc     +1.73Ki   +37%
  [ = ]       0 [Unmapped]          +1008   +66%
  +0.4%    +120 .eh_frame_hdr        +120  +0.4%
  +0.1%      +4 .gcc_except_table      +4  +0.1%
  -0.0%     -16 .bss                    0  [ = ]
  -0.0%     -32 .data                 -32  -0.0%
 -83.2%     -84 [LOAD [R]]            -84 -83.2%
  -0.2%    -240 .eh_frame            -240  -0.2%
  -0.5%  -516Ki .text              -516Ki  -0.5%
  -0.3%  -481Ki TOTAL              -483Ki  -0.3%

So, my primary fear -- AFDO causing binary size to creep up more and more over time -- isn't a reality. (Initially, it was something around 1MB .text size penalty IIRC, so it's good to see that it's a decent win in size now :) )

Looking at detailed bloaty output, I don't see anything super suspicious: we have ~1K new symbols, but ~1K have now disappeared to offset that (different inlining decisions from a new AFDO profile can cause that).  The biggest increases are:
- sqlite3VdbeExec (+31.4KB, or +103%), which I've seen in size fluctuations before. It's a large function with a lot of function calls that shows up now and again in AFDO profiles. If we classify it as hot, we'll happy inline a lot of those functions.
- blink::HTMLTokenizer::NextToken (+11.7KB, or +17%), v8::internal::compiler::CodeGenerator::AssembleArchInstruction (+11.2KB, or +20%). Both of these are already really large. Similar story about "if this profile happens to make them appear hotter", ...

And it goes down from there.

All of this is to say that I don't immediately see a single thing causing this. Perhaps we should add a Linux-specific note (Android's binary size swings are far more tame, since we use AFDO profiles to optimize for size more heavily than performance) to the commit messages specifying something like 400KB, but a 900KB swing IMO is definitely worth flagging for me to stare at for a bit.

Since this is general AFDO-related noise, duping against the AFDO noise bug