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

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


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

Google Chrome Linux x64

gbiv: Looks like an 800k binary size increase.

Ouch. Will try to look into this later today -- thanks!

$ ~/environments/bloaty/build/bloaty LinuxFresh/chrome -- LinuxFreshOldProf/chrome
     VM SIZE                     FILE SIZE
 --------------               --------------
  [ = ]       0 .debug_ranges  +769Ki  +1.0%
  [ = ]       0 .debug_loc     +374Ki  +0.1%
  [ = ]       0 .debug_line    +110Ki  +0.1%
  [ = ]       0 .debug_abbrev +19.8Ki  +0.0%
  [ = ]       0 .debug_frame  +10.7Ki  +0.1%
  [ = ]       0 .strtab       +5.36Ki  +0.0%
  [ = ]       0 .symtab       +3.14Ki  +0.0%
  +0.0% +2.37Ki .rela.dyn     +2.37Ki  +0.0%
  +0.0% +1.95Ki .rodata       +1.95Ki  +0.0%
  +0.0% +1.56Ki .data.rel.ro  +1.56Ki  +0.0%
  +0.0% +1.45Ki .text         +1.45Ki  +0.0%
  +184%    +136 [LOAD [R]]       +136  +184%
  -0.0%      -8 .eh_frame_hdr      -8  -0.0%
  -0.0%     -16 .bss                0  [ = ]
  -0.0%     -48 .eh_frame         -48  -0.0%
 -65.6% -1.56Ki [LOAD [RW]]         0  [ = ]
  [ = ]       0 [Unmapped]    -1.86Ki -51.1%
  [ = ]       0 .debug_str    -20.6Ki  -0.0%
  [ = ]       0 .gdb_index    -82.6Ki  -0.0%
  [ = ]       0 .debug_info    -380Ki  -0.0%
  +0.0% +5.84Ki TOTAL          +815Ki  +0.0%

So on the bright side, this is at least constrained to debuginfo. Still pretty odd that an AFDO roll is causing such a large debug_{ranges,loc,line} bloat, but less concerning than, say, an 800KB increase in .text.

Will continue to dig.

Chatted offline with a local DWARF expert, since I have no clue how to debug debuginfo. They noted that if the binary started at 5-6GB, numbers like these are within the noise for a change as broad as an AFDO roll.

They noted that the biggest piece, .debug_ranges, can generally increase when the compiler starts "juggling things around" more (e.g. interleaving the code from two `if` blocks, ... anything where two independent scopes are now somewhat mixed). They also noted that if this is problematic, we should probably look into split dwarf (which we appear to have enabled in is_debug builds).

WontFixing since we ship stripped binaries anyway, so I don't see how this impacts our users (or devs, since, like said, 5GB is a lot :) ). Please reopen if you disagree.